2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* linux/fs/fcntl.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 1991, 1992 Linus Torvalds
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/syscalls.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/file.h>
|
2008-04-24 05:44:08 -06:00
|
|
|
#include <linux/fdtable.h>
|
2006-01-11 13:17:46 -07:00
|
|
|
#include <linux/capability.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/dnotify.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/module.h>
|
2010-05-20 02:43:18 -06:00
|
|
|
#include <linux/pipe_fs_i.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/security.h>
|
|
|
|
#include <linux/ptrace.h>
|
2005-05-01 09:59:14 -06:00
|
|
|
#include <linux/signal.h>
|
2005-09-09 14:04:13 -06:00
|
|
|
#include <linux/rcupdate.h>
|
2007-10-19 00:40:14 -06:00
|
|
|
#include <linux/pid_namespace.h>
|
2012-07-30 15:43:00 -06:00
|
|
|
#include <linux/user_namespace.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
#include <asm/poll.h>
|
|
|
|
#include <asm/siginfo.h>
|
|
|
|
#include <asm/uaccess.h>
|
|
|
|
|
2009-02-01 14:26:59 -07:00
|
|
|
#define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | O_NOATIME)
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
static int setfl(int fd, struct file * filp, unsigned long arg)
|
|
|
|
{
|
2013-01-23 15:07:38 -07:00
|
|
|
struct inode * inode = file_inode(filp);
|
2005-04-16 16:20:36 -06:00
|
|
|
int error = 0;
|
|
|
|
|
2006-02-03 04:04:30 -07:00
|
|
|
/*
|
|
|
|
* O_APPEND cannot be cleared if the file is marked as append-only
|
|
|
|
* and the file is open for write.
|
|
|
|
*/
|
|
|
|
if (((arg ^ filp->f_flags) & O_APPEND) && IS_APPEND(inode))
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
/* O_NOATIME can only be set by the owner or superuser */
|
|
|
|
if ((arg & O_NOATIME) && !(filp->f_flags & O_NOATIME))
|
2011-03-23 17:43:26 -06:00
|
|
|
if (!inode_owner_or_capable(inode))
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
/* required for strict SunOS emulation */
|
|
|
|
if (O_NONBLOCK != O_NDELAY)
|
|
|
|
if (arg & O_NDELAY)
|
|
|
|
arg |= O_NONBLOCK;
|
|
|
|
|
|
|
|
if (arg & O_DIRECT) {
|
|
|
|
if (!filp->f_mapping || !filp->f_mapping->a_ops ||
|
|
|
|
!filp->f_mapping->a_ops->direct_IO)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (filp->f_op && filp->f_op->check_flags)
|
|
|
|
error = filp->f_op->check_flags(arg);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
|
2008-12-05 16:12:48 -07:00
|
|
|
/*
|
2009-02-01 14:26:59 -07:00
|
|
|
* ->fasync() is responsible for setting the FASYNC bit.
|
2008-12-05 16:12:48 -07:00
|
|
|
*/
|
2009-02-01 14:26:59 -07:00
|
|
|
if (((arg ^ filp->f_flags) & FASYNC) && filp->f_op &&
|
|
|
|
filp->f_op->fasync) {
|
|
|
|
error = filp->f_op->fasync(fd, filp, (arg & FASYNC) != 0);
|
|
|
|
if (error < 0)
|
|
|
|
goto out;
|
2009-02-01 14:52:56 -07:00
|
|
|
if (error > 0)
|
|
|
|
error = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2009-02-06 15:25:24 -07:00
|
|
|
spin_lock(&filp->f_lock);
|
2005-04-16 16:20:36 -06:00
|
|
|
filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);
|
2009-02-06 15:25:24 -07:00
|
|
|
spin_unlock(&filp->f_lock);
|
2009-02-01 14:26:59 -07:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
out:
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2006-10-02 03:17:15 -06:00
|
|
|
static void f_modown(struct file *filp, struct pid *pid, enum pid_type type,
|
2009-06-16 14:07:46 -06:00
|
|
|
int force)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2010-02-07 11:11:23 -07:00
|
|
|
write_lock_irq(&filp->f_owner.lock);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (force || !filp->f_owner.pid) {
|
2006-10-02 03:17:15 -06:00
|
|
|
put_pid(filp->f_owner.pid);
|
|
|
|
filp->f_owner.pid = get_pid(pid);
|
|
|
|
filp->f_owner.pid_type = type;
|
2009-06-16 14:07:46 -06:00
|
|
|
|
|
|
|
if (pid) {
|
|
|
|
const struct cred *cred = current_cred();
|
|
|
|
filp->f_owner.uid = cred->uid;
|
|
|
|
filp->f_owner.euid = cred->euid;
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2010-02-07 11:11:23 -07:00
|
|
|
write_unlock_irq(&filp->f_owner.lock);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-10-02 03:17:15 -06:00
|
|
|
int __f_setown(struct file *filp, struct pid *pid, enum pid_type type,
|
|
|
|
int force)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
int err;
|
2009-06-16 14:07:46 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
err = security_file_set_fowner(filp);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2009-06-16 14:07:46 -06:00
|
|
|
f_modown(filp, pid, type, force);
|
2005-04-16 16:20:36 -06:00
|
|
|
return 0;
|
|
|
|
}
|
2006-10-02 03:17:15 -06:00
|
|
|
EXPORT_SYMBOL(__f_setown);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-10-02 03:17:15 -06:00
|
|
|
int f_setown(struct file *filp, unsigned long arg, int force)
|
|
|
|
{
|
|
|
|
enum pid_type type;
|
|
|
|
struct pid *pid;
|
|
|
|
int who = arg;
|
|
|
|
int result;
|
|
|
|
type = PIDTYPE_PID;
|
|
|
|
if (who < 0) {
|
|
|
|
type = PIDTYPE_PGID;
|
|
|
|
who = -who;
|
|
|
|
}
|
|
|
|
rcu_read_lock();
|
2007-10-19 00:40:14 -06:00
|
|
|
pid = find_vpid(who);
|
2006-10-02 03:17:15 -06:00
|
|
|
result = __f_setown(filp, pid, type, force);
|
|
|
|
rcu_read_unlock();
|
|
|
|
return result;
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
EXPORT_SYMBOL(f_setown);
|
|
|
|
|
|
|
|
void f_delown(struct file *filp)
|
|
|
|
{
|
2009-06-16 14:07:46 -06:00
|
|
|
f_modown(filp, NULL, PIDTYPE_PID, 1);
|
2006-10-02 03:17:15 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
pid_t f_getown(struct file *filp)
|
|
|
|
{
|
|
|
|
pid_t pid;
|
2006-10-02 03:17:27 -06:00
|
|
|
read_lock(&filp->f_owner.lock);
|
2008-02-08 05:19:20 -07:00
|
|
|
pid = pid_vnr(filp->f_owner.pid);
|
2006-10-02 03:17:15 -06:00
|
|
|
if (filp->f_owner.pid_type == PIDTYPE_PGID)
|
|
|
|
pid = -pid;
|
2006-10-02 03:17:27 -06:00
|
|
|
read_unlock(&filp->f_owner.lock);
|
2006-10-02 03:17:15 -06:00
|
|
|
return pid;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2009-09-23 16:57:03 -06:00
|
|
|
static int f_setown_ex(struct file *filp, unsigned long arg)
|
|
|
|
{
|
2012-09-26 19:43:05 -06:00
|
|
|
struct f_owner_ex __user *owner_p = (void __user *)arg;
|
2009-09-23 16:57:03 -06:00
|
|
|
struct f_owner_ex owner;
|
|
|
|
struct pid *pid;
|
|
|
|
int type;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = copy_from_user(&owner, owner_p, sizeof(owner));
|
|
|
|
if (ret)
|
2010-06-03 04:35:42 -06:00
|
|
|
return -EFAULT;
|
2009-09-23 16:57:03 -06:00
|
|
|
|
|
|
|
switch (owner.type) {
|
|
|
|
case F_OWNER_TID:
|
|
|
|
type = PIDTYPE_MAX;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case F_OWNER_PID:
|
|
|
|
type = PIDTYPE_PID;
|
|
|
|
break;
|
|
|
|
|
2009-11-17 15:06:24 -07:00
|
|
|
case F_OWNER_PGRP:
|
2009-09-23 16:57:03 -06:00
|
|
|
type = PIDTYPE_PGID;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
pid = find_vpid(owner.pid);
|
|
|
|
if (owner.pid && !pid)
|
|
|
|
ret = -ESRCH;
|
|
|
|
else
|
|
|
|
ret = __f_setown(filp, pid, type, 1);
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int f_getown_ex(struct file *filp, unsigned long arg)
|
|
|
|
{
|
2012-09-26 19:43:05 -06:00
|
|
|
struct f_owner_ex __user *owner_p = (void __user *)arg;
|
2009-09-23 16:57:03 -06:00
|
|
|
struct f_owner_ex owner;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
read_lock(&filp->f_owner.lock);
|
|
|
|
owner.pid = pid_vnr(filp->f_owner.pid);
|
|
|
|
switch (filp->f_owner.pid_type) {
|
|
|
|
case PIDTYPE_MAX:
|
|
|
|
owner.type = F_OWNER_TID;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PIDTYPE_PID:
|
|
|
|
owner.type = F_OWNER_PID;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PIDTYPE_PGID:
|
2009-11-17 15:06:24 -07:00
|
|
|
owner.type = F_OWNER_PGRP;
|
2009-09-23 16:57:03 -06:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
WARN_ON(1);
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
read_unlock(&filp->f_owner.lock);
|
|
|
|
|
2010-06-03 04:35:42 -06:00
|
|
|
if (!ret) {
|
2009-09-23 16:57:03 -06:00
|
|
|
ret = copy_to_user(owner_p, &owner, sizeof(owner));
|
2010-06-03 04:35:42 -06:00
|
|
|
if (ret)
|
|
|
|
ret = -EFAULT;
|
|
|
|
}
|
2009-09-23 16:57:03 -06:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-07-30 15:43:00 -06:00
|
|
|
#ifdef CONFIG_CHECKPOINT_RESTORE
|
|
|
|
static int f_getowner_uids(struct file *filp, unsigned long arg)
|
|
|
|
{
|
|
|
|
struct user_namespace *user_ns = current_user_ns();
|
2012-09-26 19:43:05 -06:00
|
|
|
uid_t __user *dst = (void __user *)arg;
|
2012-07-30 15:43:00 -06:00
|
|
|
uid_t src[2];
|
|
|
|
int err;
|
|
|
|
|
|
|
|
read_lock(&filp->f_owner.lock);
|
|
|
|
src[0] = from_kuid(user_ns, filp->f_owner.uid);
|
|
|
|
src[1] = from_kuid(user_ns, filp->f_owner.euid);
|
|
|
|
read_unlock(&filp->f_owner.lock);
|
|
|
|
|
|
|
|
err = put_user(src[0], &dst[0]);
|
|
|
|
err |= put_user(src[1], &dst[1]);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static int f_getowner_uids(struct file *filp, unsigned long arg)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
static long do_fcntl(int fd, unsigned int cmd, unsigned long arg,
|
|
|
|
struct file *filp)
|
|
|
|
{
|
|
|
|
long err = -EINVAL;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case F_DUPFD:
|
2012-08-21 09:48:11 -06:00
|
|
|
err = f_dupfd(arg, filp, 0);
|
|
|
|
break;
|
F_DUPFD_CLOEXEC implementation
One more small change to extend the availability of creation of file
descriptors with FD_CLOEXEC set. Adding a new command to fcntl() requires
no new system call and the overall impact on code size if minimal.
If this patch gets accepted we will also add this change to the next
revision of the POSIX spec.
To test the patch, use the following little program. Adjust the value of
F_DUPFD_CLOEXEC appropriately.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#ifndef F_DUPFD_CLOEXEC
# define F_DUPFD_CLOEXEC 12
#endif
int
main (int argc, char *argv[])
{
if (argc > 1)
{
if (fcntl (3, F_GETFD) == 0)
{
puts ("descriptor not closed");
exit (1);
}
if (errno != EBADF)
{
puts ("error not EBADF");
exit (1);
}
exit (0);
}
int fd = fcntl (STDOUT_FILENO, F_DUPFD_CLOEXEC, 0);
if (fd == -1 && errno == EINVAL)
{
puts ("F_DUPFD_CLOEXEC not supported");
return 0;
}
if (fd != 3)
{
puts ("program called with descriptors other than 0,1,2");
return 1;
}
execl ("/proc/self/exe", "/proc/self/exe", "1", NULL);
puts ("execl failed");
return 1;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Ulrich Drepper <drepper@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <linux-arch@vger.kernel.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-17 00:30:26 -06:00
|
|
|
case F_DUPFD_CLOEXEC:
|
2012-10-08 16:21:58 -06:00
|
|
|
err = f_dupfd(arg, filp, O_CLOEXEC);
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
case F_GETFD:
|
|
|
|
err = get_close_on_exec(fd) ? FD_CLOEXEC : 0;
|
|
|
|
break;
|
|
|
|
case F_SETFD:
|
|
|
|
err = 0;
|
|
|
|
set_close_on_exec(fd, arg & FD_CLOEXEC);
|
|
|
|
break;
|
|
|
|
case F_GETFL:
|
|
|
|
err = filp->f_flags;
|
|
|
|
break;
|
|
|
|
case F_SETFL:
|
|
|
|
err = setfl(fd, filp, arg);
|
|
|
|
break;
|
|
|
|
case F_GETLK:
|
|
|
|
err = fcntl_getlk(filp, (struct flock __user *) arg);
|
|
|
|
break;
|
|
|
|
case F_SETLK:
|
|
|
|
case F_SETLKW:
|
[PATCH] stale POSIX lock handling
I believe that there is a problem with the handling of POSIX locks, which
the attached patch should address.
The problem appears to be a race between fcntl(2) and close(2). A
multithreaded application could close a file descriptor at the same time as
it is trying to acquire a lock using the same file descriptor. I would
suggest that that multithreaded application is not providing the proper
synchronization for itself, but the OS should still behave correctly.
SUS3 (Single UNIX Specification Version 3, read: POSIX) indicates that when
a file descriptor is closed, that all POSIX locks on the file, owned by the
process which closed the file descriptor, should be released.
The trick here is when those locks are released. The current code releases
all locks which exist when close is processing, but any locks in progress
are handled when the last reference to the open file is released.
There are three cases to consider.
One is the simple case, a multithreaded (mt) process has a file open and
races to close it and acquire a lock on it. In this case, the close will
release one reference to the open file and when the fcntl is done, it will
release the other reference. For this situation, no locks should exist on
the file when both the close and fcntl operations are done. The current
system will handle this case because the last reference to the open file is
being released.
The second case is when the mt process has dup(2)'d the file descriptor.
The close will release one reference to the file and the fcntl, when done,
will release another, but there will still be at least one more reference
to the open file. One could argue that the existence of a lock on the file
after the close has completed is okay, because it was acquired after the
close operation and there is still a way for the application to release the
lock on the file, using an existing file descriptor.
The third case is when the mt process has forked, after opening the file
and either before or after becoming an mt process. In this case, each
process would hold a reference to the open file. For each process, this
degenerates to first case above. However, the lock continues to exist
until both processes have released their references to the open file. This
lock could block other lock requests.
The changes to release the lock when the last reference to the open file
aren't quite right because they would allow the lock to exist as long as
there was a reference to the open file. This is too long.
The new proposed solution is to add support in the fcntl code path to
detect a race with close and then to release the lock which was just
acquired when such as race is detected. This causes locks to be released
in a timely fashion and for the system to conform to the POSIX semantic
specification.
This was tested by instrumenting a kernel to detect the handling locks and
then running a program which generates case #3 above. A dangling lock
could be reliably generated. When the changes to detect the close/fcntl
race were added, a dangling lock could no longer be generated.
Cc: Matthew Wilcox <willy@debian.org>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 12:45:09 -06:00
|
|
|
err = fcntl_setlk(fd, filp, cmd, (struct flock __user *) arg);
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
case F_GETOWN:
|
|
|
|
/*
|
|
|
|
* XXX If f_owner is a process group, the
|
|
|
|
* negative return value will get converted
|
|
|
|
* into an error. Oops. If we keep the
|
|
|
|
* current syscall conventions, the only way
|
|
|
|
* to fix this will be in libc.
|
|
|
|
*/
|
2006-10-02 03:17:15 -06:00
|
|
|
err = f_getown(filp);
|
2005-04-16 16:20:36 -06:00
|
|
|
force_successful_syscall_return();
|
|
|
|
break;
|
|
|
|
case F_SETOWN:
|
|
|
|
err = f_setown(filp, arg, 1);
|
|
|
|
break;
|
2009-09-23 16:57:03 -06:00
|
|
|
case F_GETOWN_EX:
|
|
|
|
err = f_getown_ex(filp, arg);
|
|
|
|
break;
|
|
|
|
case F_SETOWN_EX:
|
|
|
|
err = f_setown_ex(filp, arg);
|
|
|
|
break;
|
2012-07-30 15:43:00 -06:00
|
|
|
case F_GETOWNER_UIDS:
|
|
|
|
err = f_getowner_uids(filp, arg);
|
|
|
|
break;
|
2005-04-16 16:20:36 -06:00
|
|
|
case F_GETSIG:
|
|
|
|
err = filp->f_owner.signum;
|
|
|
|
break;
|
|
|
|
case F_SETSIG:
|
|
|
|
/* arg == 0 restores default behaviour. */
|
2005-05-01 09:59:14 -06:00
|
|
|
if (!valid_signal(arg)) {
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
err = 0;
|
|
|
|
filp->f_owner.signum = arg;
|
|
|
|
break;
|
|
|
|
case F_GETLEASE:
|
|
|
|
err = fcntl_getlease(filp);
|
|
|
|
break;
|
|
|
|
case F_SETLEASE:
|
|
|
|
err = fcntl_setlease(fd, filp, arg);
|
|
|
|
break;
|
|
|
|
case F_NOTIFY:
|
|
|
|
err = fcntl_dirnotify(fd, filp, arg);
|
|
|
|
break;
|
2010-05-20 02:43:18 -06:00
|
|
|
case F_SETPIPE_SZ:
|
|
|
|
case F_GETPIPE_SZ:
|
|
|
|
err = pipe_fcntl(filp, cmd, arg);
|
|
|
|
break;
|
2005-04-16 16:20:36 -06:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
New kind of open files - "location only".
New flag for open(2) - O_PATH. Semantics:
* pathname is resolved, but the file itself is _NOT_ opened
as far as filesystem is concerned.
* almost all operations on the resulting descriptors shall
fail with -EBADF. Exceptions are:
1) operations on descriptors themselves (i.e.
close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
fcntl(fd, F_SETFD, ...))
2) fcntl(fd, F_GETFL), for a common non-destructive way to
check if descriptor is open
3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
points of pathname resolution
* closing such descriptor does *NOT* affect dnotify or
posix locks.
* permissions are checked as usual along the way to file;
no permission checks are applied to the file itself. Of course,
giving such thing to syscall will result in permission checks (at
the moment it means checking that starting point of ....at() is
a directory and caller has exec permissions on it).
fget() and fget_light() return NULL on such descriptors; use of
fget_raw() and fget_raw_light() is needed to get them. That protects
existing code from dealing with those things.
There are two things still missing (they come in the next commits):
one is handling of symlinks (right now we refuse to open them that
way; see the next commit for semantics related to those) and another
is descriptor passing via SCM_RIGHTS datagrams.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-03-13 00:51:11 -07:00
|
|
|
static int check_fcntl_cmd(unsigned cmd)
|
|
|
|
{
|
|
|
|
switch (cmd) {
|
|
|
|
case F_DUPFD:
|
|
|
|
case F_DUPFD_CLOEXEC:
|
|
|
|
case F_GETFD:
|
|
|
|
case F_SETFD:
|
|
|
|
case F_GETFL:
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-01-14 06:14:17 -07:00
|
|
|
SYSCALL_DEFINE3(fcntl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2012-08-28 10:52:22 -06:00
|
|
|
struct fd f = fdget_raw(fd);
|
2005-04-16 16:20:36 -06:00
|
|
|
long err = -EBADF;
|
|
|
|
|
2012-08-28 10:52:22 -06:00
|
|
|
if (!f.file)
|
2005-04-16 16:20:36 -06:00
|
|
|
goto out;
|
|
|
|
|
2012-08-28 10:52:22 -06:00
|
|
|
if (unlikely(f.file->f_mode & FMODE_PATH)) {
|
2012-04-21 16:42:19 -06:00
|
|
|
if (!check_fcntl_cmd(cmd))
|
|
|
|
goto out1;
|
New kind of open files - "location only".
New flag for open(2) - O_PATH. Semantics:
* pathname is resolved, but the file itself is _NOT_ opened
as far as filesystem is concerned.
* almost all operations on the resulting descriptors shall
fail with -EBADF. Exceptions are:
1) operations on descriptors themselves (i.e.
close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
fcntl(fd, F_SETFD, ...))
2) fcntl(fd, F_GETFL), for a common non-destructive way to
check if descriptor is open
3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
points of pathname resolution
* closing such descriptor does *NOT* affect dnotify or
posix locks.
* permissions are checked as usual along the way to file;
no permission checks are applied to the file itself. Of course,
giving such thing to syscall will result in permission checks (at
the moment it means checking that starting point of ....at() is
a directory and caller has exec permissions on it).
fget() and fget_light() return NULL on such descriptors; use of
fget_raw() and fget_raw_light() is needed to get them. That protects
existing code from dealing with those things.
There are two things still missing (they come in the next commits):
one is handling of symlinks (right now we refuse to open them that
way; see the next commit for semantics related to those) and another
is descriptor passing via SCM_RIGHTS datagrams.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-03-13 00:51:11 -07:00
|
|
|
}
|
|
|
|
|
2012-08-28 10:52:22 -06:00
|
|
|
err = security_file_fcntl(f.file, cmd, arg);
|
2012-04-21 16:42:19 -06:00
|
|
|
if (!err)
|
2012-08-28 10:52:22 -06:00
|
|
|
err = do_fcntl(fd, cmd, arg, f.file);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2012-04-21 16:42:19 -06:00
|
|
|
out1:
|
2012-08-28 10:52:22 -06:00
|
|
|
fdput(f);
|
2005-04-16 16:20:36 -06:00
|
|
|
out:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
#if BITS_PER_LONG == 32
|
2009-01-14 06:14:17 -07:00
|
|
|
SYSCALL_DEFINE3(fcntl64, unsigned int, fd, unsigned int, cmd,
|
|
|
|
unsigned long, arg)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2012-08-28 10:52:22 -06:00
|
|
|
struct fd f = fdget_raw(fd);
|
2012-04-21 16:42:19 -06:00
|
|
|
long err = -EBADF;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2012-08-28 10:52:22 -06:00
|
|
|
if (!f.file)
|
2005-04-16 16:20:36 -06:00
|
|
|
goto out;
|
|
|
|
|
2012-08-28 10:52:22 -06:00
|
|
|
if (unlikely(f.file->f_mode & FMODE_PATH)) {
|
2012-04-21 16:42:19 -06:00
|
|
|
if (!check_fcntl_cmd(cmd))
|
|
|
|
goto out1;
|
New kind of open files - "location only".
New flag for open(2) - O_PATH. Semantics:
* pathname is resolved, but the file itself is _NOT_ opened
as far as filesystem is concerned.
* almost all operations on the resulting descriptors shall
fail with -EBADF. Exceptions are:
1) operations on descriptors themselves (i.e.
close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
fcntl(fd, F_SETFD, ...))
2) fcntl(fd, F_GETFL), for a common non-destructive way to
check if descriptor is open
3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
points of pathname resolution
* closing such descriptor does *NOT* affect dnotify or
posix locks.
* permissions are checked as usual along the way to file;
no permission checks are applied to the file itself. Of course,
giving such thing to syscall will result in permission checks (at
the moment it means checking that starting point of ....at() is
a directory and caller has exec permissions on it).
fget() and fget_light() return NULL on such descriptors; use of
fget_raw() and fget_raw_light() is needed to get them. That protects
existing code from dealing with those things.
There are two things still missing (they come in the next commits):
one is handling of symlinks (right now we refuse to open them that
way; see the next commit for semantics related to those) and another
is descriptor passing via SCM_RIGHTS datagrams.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-03-13 00:51:11 -07:00
|
|
|
}
|
|
|
|
|
2012-08-28 10:52:22 -06:00
|
|
|
err = security_file_fcntl(f.file, cmd, arg);
|
2012-04-21 16:42:19 -06:00
|
|
|
if (err)
|
|
|
|
goto out1;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case F_GETLK64:
|
2012-08-28 10:52:22 -06:00
|
|
|
err = fcntl_getlk64(f.file, (struct flock64 __user *) arg);
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
case F_SETLK64:
|
|
|
|
case F_SETLKW64:
|
2012-08-28 10:52:22 -06:00
|
|
|
err = fcntl_setlk64(fd, f.file, cmd,
|
[PATCH] stale POSIX lock handling
I believe that there is a problem with the handling of POSIX locks, which
the attached patch should address.
The problem appears to be a race between fcntl(2) and close(2). A
multithreaded application could close a file descriptor at the same time as
it is trying to acquire a lock using the same file descriptor. I would
suggest that that multithreaded application is not providing the proper
synchronization for itself, but the OS should still behave correctly.
SUS3 (Single UNIX Specification Version 3, read: POSIX) indicates that when
a file descriptor is closed, that all POSIX locks on the file, owned by the
process which closed the file descriptor, should be released.
The trick here is when those locks are released. The current code releases
all locks which exist when close is processing, but any locks in progress
are handled when the last reference to the open file is released.
There are three cases to consider.
One is the simple case, a multithreaded (mt) process has a file open and
races to close it and acquire a lock on it. In this case, the close will
release one reference to the open file and when the fcntl is done, it will
release the other reference. For this situation, no locks should exist on
the file when both the close and fcntl operations are done. The current
system will handle this case because the last reference to the open file is
being released.
The second case is when the mt process has dup(2)'d the file descriptor.
The close will release one reference to the file and the fcntl, when done,
will release another, but there will still be at least one more reference
to the open file. One could argue that the existence of a lock on the file
after the close has completed is okay, because it was acquired after the
close operation and there is still a way for the application to release the
lock on the file, using an existing file descriptor.
The third case is when the mt process has forked, after opening the file
and either before or after becoming an mt process. In this case, each
process would hold a reference to the open file. For each process, this
degenerates to first case above. However, the lock continues to exist
until both processes have released their references to the open file. This
lock could block other lock requests.
The changes to release the lock when the last reference to the open file
aren't quite right because they would allow the lock to exist as long as
there was a reference to the open file. This is too long.
The new proposed solution is to add support in the fcntl code path to
detect a race with close and then to release the lock which was just
acquired when such as race is detected. This causes locks to be released
in a timely fashion and for the system to conform to the POSIX semantic
specification.
This was tested by instrumenting a kernel to detect the handling locks and
then running a program which generates case #3 above. A dangling lock
could be reliably generated. When the changes to detect the close/fcntl
race were added, a dangling lock could no longer be generated.
Cc: Matthew Wilcox <willy@debian.org>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 12:45:09 -06:00
|
|
|
(struct flock64 __user *) arg);
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
default:
|
2012-08-28 10:52:22 -06:00
|
|
|
err = do_fcntl(fd, cmd, arg, f.file);
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
}
|
2012-04-21 16:42:19 -06:00
|
|
|
out1:
|
2012-08-28 10:52:22 -06:00
|
|
|
fdput(f);
|
2005-04-16 16:20:36 -06:00
|
|
|
out:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Table to convert sigio signal codes into poll band bitmaps */
|
|
|
|
|
2006-03-26 02:37:24 -07:00
|
|
|
static const long band_table[NSIGPOLL] = {
|
2005-04-16 16:20:36 -06:00
|
|
|
POLLIN | POLLRDNORM, /* POLL_IN */
|
|
|
|
POLLOUT | POLLWRNORM | POLLWRBAND, /* POLL_OUT */
|
|
|
|
POLLIN | POLLRDNORM | POLLMSG, /* POLL_MSG */
|
|
|
|
POLLERR, /* POLL_ERR */
|
|
|
|
POLLPRI | POLLRDBAND, /* POLL_PRI */
|
|
|
|
POLLHUP | POLLERR /* POLL_HUP */
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline int sigio_perm(struct task_struct *p,
|
|
|
|
struct fown_struct *fown, int sig)
|
|
|
|
{
|
2008-11-13 16:39:19 -07:00
|
|
|
const struct cred *cred;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
cred = __task_cred(p);
|
2012-03-03 22:17:15 -07:00
|
|
|
ret = ((uid_eq(fown->euid, GLOBAL_ROOT_UID) ||
|
|
|
|
uid_eq(fown->euid, cred->suid) || uid_eq(fown->euid, cred->uid) ||
|
|
|
|
uid_eq(fown->uid, cred->suid) || uid_eq(fown->uid, cred->uid)) &&
|
2008-11-13 16:39:19 -07:00
|
|
|
!security_file_send_sigiotask(p, fown, sig));
|
|
|
|
rcu_read_unlock();
|
|
|
|
return ret;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static void send_sigio_to_task(struct task_struct *p,
|
2009-06-16 16:27:10 -06:00
|
|
|
struct fown_struct *fown,
|
2009-09-23 16:57:03 -06:00
|
|
|
int fd, int reason, int group)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2009-06-16 16:27:10 -06:00
|
|
|
/*
|
|
|
|
* F_SETSIG can change ->signum lockless in parallel, make
|
|
|
|
* sure we read it once and use the same value throughout.
|
|
|
|
*/
|
|
|
|
int signum = ACCESS_ONCE(fown->signum);
|
|
|
|
|
|
|
|
if (!sigio_perm(p, fown, signum))
|
2005-04-16 16:20:36 -06:00
|
|
|
return;
|
|
|
|
|
2009-06-16 16:27:10 -06:00
|
|
|
switch (signum) {
|
2005-04-16 16:20:36 -06:00
|
|
|
siginfo_t si;
|
|
|
|
default:
|
|
|
|
/* Queue a rt signal with the appropriate fd as its
|
|
|
|
value. We use SI_SIGIO as the source, not
|
|
|
|
SI_KERNEL, since kernel signals always get
|
|
|
|
delivered even if we can't queue. Failure to
|
|
|
|
queue in this case _should_ be reported; we fall
|
|
|
|
back to SIGIO in that case. --sct */
|
2009-06-16 16:27:10 -06:00
|
|
|
si.si_signo = signum;
|
2005-04-16 16:20:36 -06:00
|
|
|
si.si_errno = 0;
|
|
|
|
si.si_code = reason;
|
|
|
|
/* Make sure we are called with one of the POLL_*
|
|
|
|
reasons, otherwise we could leak kernel stack into
|
|
|
|
userspace. */
|
2006-04-02 05:37:19 -06:00
|
|
|
BUG_ON((reason & __SI_MASK) != __SI_POLL);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (reason - POLL_IN >= NSIGPOLL)
|
|
|
|
si.si_band = ~0L;
|
|
|
|
else
|
|
|
|
si.si_band = band_table[reason - POLL_IN];
|
|
|
|
si.si_fd = fd;
|
2009-09-23 16:57:03 -06:00
|
|
|
if (!do_send_sig_info(signum, &si, p, group))
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
/* fall-through: fall back on the old plain SIGIO signal */
|
|
|
|
case 0:
|
2009-09-23 16:57:03 -06:00
|
|
|
do_send_sig_info(SIGIO, SEND_SIG_PRIV, p, group);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void send_sigio(struct fown_struct *fown, int fd, int band)
|
|
|
|
{
|
|
|
|
struct task_struct *p;
|
2006-10-02 03:17:15 -06:00
|
|
|
enum pid_type type;
|
|
|
|
struct pid *pid;
|
2009-09-23 16:57:03 -06:00
|
|
|
int group = 1;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
read_lock(&fown->lock);
|
2009-09-23 16:57:03 -06:00
|
|
|
|
2006-10-02 03:17:15 -06:00
|
|
|
type = fown->pid_type;
|
2009-09-23 16:57:03 -06:00
|
|
|
if (type == PIDTYPE_MAX) {
|
|
|
|
group = 0;
|
|
|
|
type = PIDTYPE_PID;
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
pid = fown->pid;
|
|
|
|
if (!pid)
|
|
|
|
goto out_unlock_fown;
|
|
|
|
|
|
|
|
read_lock(&tasklist_lock);
|
2006-10-02 03:17:15 -06:00
|
|
|
do_each_pid_task(pid, type, p) {
|
2009-09-23 16:57:03 -06:00
|
|
|
send_sigio_to_task(p, fown, fd, band, group);
|
2006-10-02 03:17:15 -06:00
|
|
|
} while_each_pid_task(pid, type, p);
|
2005-04-16 16:20:36 -06:00
|
|
|
read_unlock(&tasklist_lock);
|
|
|
|
out_unlock_fown:
|
|
|
|
read_unlock(&fown->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void send_sigurg_to_task(struct task_struct *p,
|
2009-09-23 16:57:03 -06:00
|
|
|
struct fown_struct *fown, int group)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
if (sigio_perm(p, fown, SIGURG))
|
2009-09-23 16:57:03 -06:00
|
|
|
do_send_sig_info(SIGURG, SEND_SIG_PRIV, p, group);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
int send_sigurg(struct fown_struct *fown)
|
|
|
|
{
|
|
|
|
struct task_struct *p;
|
2006-10-02 03:17:15 -06:00
|
|
|
enum pid_type type;
|
|
|
|
struct pid *pid;
|
2009-09-23 16:57:03 -06:00
|
|
|
int group = 1;
|
2006-10-02 03:17:15 -06:00
|
|
|
int ret = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
read_lock(&fown->lock);
|
2009-09-23 16:57:03 -06:00
|
|
|
|
2006-10-02 03:17:15 -06:00
|
|
|
type = fown->pid_type;
|
2009-09-23 16:57:03 -06:00
|
|
|
if (type == PIDTYPE_MAX) {
|
|
|
|
group = 0;
|
|
|
|
type = PIDTYPE_PID;
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
pid = fown->pid;
|
|
|
|
if (!pid)
|
|
|
|
goto out_unlock_fown;
|
|
|
|
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
read_lock(&tasklist_lock);
|
2006-10-02 03:17:15 -06:00
|
|
|
do_each_pid_task(pid, type, p) {
|
2009-09-23 16:57:03 -06:00
|
|
|
send_sigurg_to_task(p, fown, group);
|
2006-10-02 03:17:15 -06:00
|
|
|
} while_each_pid_task(pid, type, p);
|
2005-04-16 16:20:36 -06:00
|
|
|
read_unlock(&tasklist_lock);
|
|
|
|
out_unlock_fown:
|
|
|
|
read_unlock(&fown->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-04-14 03:55:35 -06:00
|
|
|
static DEFINE_SPINLOCK(fasync_lock);
|
2006-12-06 21:33:20 -07:00
|
|
|
static struct kmem_cache *fasync_cache __read_mostly;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-04-14 03:55:35 -06:00
|
|
|
static void fasync_free_rcu(struct rcu_head *head)
|
|
|
|
{
|
|
|
|
kmem_cache_free(fasync_cache,
|
|
|
|
container_of(head, struct fasync_struct, fa_rcu));
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
* Remove a fasync entry. If successfully removed, return
|
|
|
|
* positive and clear the FASYNC flag. If no entry exists,
|
|
|
|
* do nothing and return 0.
|
|
|
|
*
|
|
|
|
* NOTE! It is very important that the FASYNC flag always
|
|
|
|
* match the state "is the filp on a fasync list".
|
|
|
|
*
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
2010-10-27 10:38:12 -06:00
|
|
|
int fasync_remove_entry(struct file *filp, struct fasync_struct **fapp)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
struct fasync_struct *fa, **fp;
|
|
|
|
int result = 0;
|
|
|
|
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
spin_lock(&filp->f_lock);
|
2010-04-14 03:55:35 -06:00
|
|
|
spin_lock(&fasync_lock);
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
for (fp = fapp; (fa = *fp) != NULL; fp = &fa->fa_next) {
|
|
|
|
if (fa->fa_file != filp)
|
|
|
|
continue;
|
2010-04-14 03:55:35 -06:00
|
|
|
|
|
|
|
spin_lock_irq(&fa->fa_lock);
|
|
|
|
fa->fa_file = NULL;
|
|
|
|
spin_unlock_irq(&fa->fa_lock);
|
|
|
|
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
*fp = fa->fa_next;
|
2010-04-14 03:55:35 -06:00
|
|
|
call_rcu(&fa->fa_rcu, fasync_free_rcu);
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
filp->f_flags &= ~FASYNC;
|
|
|
|
result = 1;
|
|
|
|
break;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2010-04-14 03:55:35 -06:00
|
|
|
spin_unlock(&fasync_lock);
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
spin_unlock(&filp->f_lock);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2010-10-27 10:38:12 -06:00
|
|
|
struct fasync_struct *fasync_alloc(void)
|
|
|
|
{
|
|
|
|
return kmem_cache_alloc(fasync_cache, GFP_KERNEL);
|
|
|
|
}
|
|
|
|
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
/*
|
2010-10-27 10:38:12 -06:00
|
|
|
* NOTE! This can be used only for unused fasync entries:
|
|
|
|
* entries that actually got inserted on the fasync list
|
|
|
|
* need to be released by rcu - see fasync_remove_entry.
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
*/
|
2010-10-27 10:38:12 -06:00
|
|
|
void fasync_free(struct fasync_struct *new)
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
{
|
2010-10-27 10:38:12 -06:00
|
|
|
kmem_cache_free(fasync_cache, new);
|
|
|
|
}
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
|
2010-10-27 10:38:12 -06:00
|
|
|
/*
|
|
|
|
* Insert a new entry into the fasync list. Return the pointer to the
|
|
|
|
* old one if we didn't use the new one.
|
2010-10-27 19:17:02 -06:00
|
|
|
*
|
|
|
|
* NOTE! It is very important that the FASYNC flag always
|
|
|
|
* match the state "is the filp on a fasync list".
|
2010-10-27 10:38:12 -06:00
|
|
|
*/
|
|
|
|
struct fasync_struct *fasync_insert_entry(int fd, struct file *filp, struct fasync_struct **fapp, struct fasync_struct *new)
|
|
|
|
{
|
|
|
|
struct fasync_struct *fa, **fp;
|
2009-03-27 12:24:31 -06:00
|
|
|
|
|
|
|
spin_lock(&filp->f_lock);
|
2010-04-14 03:55:35 -06:00
|
|
|
spin_lock(&fasync_lock);
|
2005-04-16 16:20:36 -06:00
|
|
|
for (fp = fapp; (fa = *fp) != NULL; fp = &fa->fa_next) {
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
if (fa->fa_file != filp)
|
|
|
|
continue;
|
2010-04-14 03:55:35 -06:00
|
|
|
|
|
|
|
spin_lock_irq(&fa->fa_lock);
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
fa->fa_fd = fd;
|
2010-04-14 03:55:35 -06:00
|
|
|
spin_unlock_irq(&fa->fa_lock);
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
goto out;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-04-14 03:55:35 -06:00
|
|
|
spin_lock_init(&new->fa_lock);
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
new->magic = FASYNC_MAGIC;
|
|
|
|
new->fa_file = filp;
|
|
|
|
new->fa_fd = fd;
|
|
|
|
new->fa_next = *fapp;
|
2010-04-14 03:55:35 -06:00
|
|
|
rcu_assign_pointer(*fapp, new);
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
filp->f_flags |= FASYNC;
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
out:
|
2010-04-14 03:55:35 -06:00
|
|
|
spin_unlock(&fasync_lock);
|
2009-03-27 12:24:31 -06:00
|
|
|
spin_unlock(&filp->f_lock);
|
2010-10-27 10:38:12 -06:00
|
|
|
return fa;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add a fasync entry. Return negative on error, positive if
|
|
|
|
* added, and zero if did nothing but change an existing one.
|
|
|
|
*/
|
|
|
|
static int fasync_add_entry(int fd, struct file *filp, struct fasync_struct **fapp)
|
|
|
|
{
|
|
|
|
struct fasync_struct *new;
|
|
|
|
|
|
|
|
new = fasync_alloc();
|
|
|
|
if (!new)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* fasync_insert_entry() returns the old (update) entry if
|
|
|
|
* it existed.
|
|
|
|
*
|
|
|
|
* So free the (unused) new entry and return 0 to let the
|
|
|
|
* caller know that we didn't add any new fasync entries.
|
|
|
|
*/
|
|
|
|
if (fasync_insert_entry(fd, filp, fapp, new)) {
|
|
|
|
fasync_free(new);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
fasync: split 'fasync_helper()' into separate add/remove functions
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16 09:23:37 -07:00
|
|
|
/*
|
|
|
|
* fasync_helper() is used by almost all character device drivers
|
|
|
|
* to set up the fasync queue, and for regular files by the file
|
|
|
|
* lease code. It returns negative on error, 0 if it did no changes
|
|
|
|
* and positive if it added/deleted the entry.
|
|
|
|
*/
|
|
|
|
int fasync_helper(int fd, struct file * filp, int on, struct fasync_struct **fapp)
|
|
|
|
{
|
|
|
|
if (!on)
|
|
|
|
return fasync_remove_entry(filp, fapp);
|
|
|
|
return fasync_add_entry(fd, filp, fapp);
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
EXPORT_SYMBOL(fasync_helper);
|
|
|
|
|
2010-04-14 03:55:35 -06:00
|
|
|
/*
|
|
|
|
* rcu_read_lock() is held
|
|
|
|
*/
|
|
|
|
static void kill_fasync_rcu(struct fasync_struct *fa, int sig, int band)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
while (fa) {
|
2010-04-14 03:55:35 -06:00
|
|
|
struct fown_struct *fown;
|
2010-06-29 16:05:42 -06:00
|
|
|
unsigned long flags;
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
if (fa->magic != FASYNC_MAGIC) {
|
|
|
|
printk(KERN_ERR "kill_fasync: bad magic number in "
|
|
|
|
"fasync_struct!\n");
|
|
|
|
return;
|
|
|
|
}
|
2010-06-29 16:05:42 -06:00
|
|
|
spin_lock_irqsave(&fa->fa_lock, flags);
|
2010-04-14 03:55:35 -06:00
|
|
|
if (fa->fa_file) {
|
|
|
|
fown = &fa->fa_file->f_owner;
|
|
|
|
/* Don't send SIGURG to processes which have not set a
|
|
|
|
queued signum: SIGURG has its own default signalling
|
|
|
|
mechanism. */
|
|
|
|
if (!(sig == SIGURG && fown->signum == 0))
|
|
|
|
send_sigio(fown, fa->fa_fd, band);
|
|
|
|
}
|
2010-06-29 16:05:42 -06:00
|
|
|
spin_unlock_irqrestore(&fa->fa_lock, flags);
|
2010-04-14 03:55:35 -06:00
|
|
|
fa = rcu_dereference(fa->fa_next);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void kill_fasync(struct fasync_struct **fp, int sig, int band)
|
|
|
|
{
|
|
|
|
/* First a quick test without locking: usually
|
|
|
|
* the list is empty.
|
|
|
|
*/
|
|
|
|
if (*fp) {
|
2010-04-14 03:55:35 -06:00
|
|
|
rcu_read_lock();
|
|
|
|
kill_fasync_rcu(rcu_dereference(*fp), sig, band);
|
|
|
|
rcu_read_unlock();
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kill_fasync);
|
|
|
|
|
2010-08-10 19:01:29 -06:00
|
|
|
static int __init fcntl_init(void)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2010-09-09 17:38:12 -06:00
|
|
|
/*
|
|
|
|
* Please add new bits here to ensure allocation uniqueness.
|
|
|
|
* Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
|
|
|
|
* is defined as O_NONBLOCK on some platforms and not on others.
|
|
|
|
*/
|
New kind of open files - "location only".
New flag for open(2) - O_PATH. Semantics:
* pathname is resolved, but the file itself is _NOT_ opened
as far as filesystem is concerned.
* almost all operations on the resulting descriptors shall
fail with -EBADF. Exceptions are:
1) operations on descriptors themselves (i.e.
close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
fcntl(fd, F_SETFD, ...))
2) fcntl(fd, F_GETFL), for a common non-destructive way to
check if descriptor is open
3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
points of pathname resolution
* closing such descriptor does *NOT* affect dnotify or
posix locks.
* permissions are checked as usual along the way to file;
no permission checks are applied to the file itself. Of course,
giving such thing to syscall will result in permission checks (at
the moment it means checking that starting point of ....at() is
a directory and caller has exec permissions on it).
fget() and fget_light() return NULL on such descriptors; use of
fget_raw() and fget_raw_light() is needed to get them. That protects
existing code from dealing with those things.
There are two things still missing (they come in the next commits):
one is handling of symlinks (right now we refuse to open them that
way; see the next commit for semantics related to those) and another
is descriptor passing via SCM_RIGHTS datagrams.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-03-13 00:51:11 -07:00
|
|
|
BUILD_BUG_ON(19 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
|
2010-08-10 19:01:29 -06:00
|
|
|
O_RDONLY | O_WRONLY | O_RDWR |
|
|
|
|
O_CREAT | O_EXCL | O_NOCTTY |
|
2010-09-09 17:38:12 -06:00
|
|
|
O_TRUNC | O_APPEND | /* O_NONBLOCK | */
|
2010-08-10 19:01:29 -06:00
|
|
|
__O_SYNC | O_DSYNC | FASYNC |
|
|
|
|
O_DIRECT | O_LARGEFILE | O_DIRECTORY |
|
|
|
|
O_NOFOLLOW | O_NOATIME | O_CLOEXEC |
|
New kind of open files - "location only".
New flag for open(2) - O_PATH. Semantics:
* pathname is resolved, but the file itself is _NOT_ opened
as far as filesystem is concerned.
* almost all operations on the resulting descriptors shall
fail with -EBADF. Exceptions are:
1) operations on descriptors themselves (i.e.
close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
fcntl(fd, F_SETFD, ...))
2) fcntl(fd, F_GETFL), for a common non-destructive way to
check if descriptor is open
3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
points of pathname resolution
* closing such descriptor does *NOT* affect dnotify or
posix locks.
* permissions are checked as usual along the way to file;
no permission checks are applied to the file itself. Of course,
giving such thing to syscall will result in permission checks (at
the moment it means checking that starting point of ....at() is
a directory and caller has exec permissions on it).
fget() and fget_light() return NULL on such descriptors; use of
fget_raw() and fget_raw_light() is needed to get them. That protects
existing code from dealing with those things.
There are two things still missing (they come in the next commits):
one is handling of symlinks (right now we refuse to open them that
way; see the next commit for semantics related to those) and another
is descriptor passing via SCM_RIGHTS datagrams.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-03-13 00:51:11 -07:00
|
|
|
__FMODE_EXEC | O_PATH
|
2010-08-10 19:01:29 -06:00
|
|
|
));
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
fasync_cache = kmem_cache_create("fasync_cache",
|
2007-07-19 19:11:58 -06:00
|
|
|
sizeof(struct fasync_struct), 0, SLAB_PANIC, NULL);
|
2005-04-16 16:20:36 -06:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-08-10 19:01:29 -06:00
|
|
|
module_init(fcntl_init)
|