2005-04-17 02:20:36 +04: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 15:44:08 +04:00
# include <linux/fdtable.h>
2006-01-11 23:17:46 +03:00
# include <linux/capability.h>
2005-04-17 02:20:36 +04:00
# include <linux/dnotify.h>
# include <linux/slab.h>
# include <linux/module.h>
2010-05-20 12:43:18 +04:00
# include <linux/pipe_fs_i.h>
2005-04-17 02:20:36 +04:00
# include <linux/security.h>
# include <linux/ptrace.h>
2005-05-01 19:59:14 +04:00
# include <linux/signal.h>
2005-09-10 00:04:13 +04:00
# include <linux/rcupdate.h>
2007-10-19 10:40:14 +04:00
# include <linux/pid_namespace.h>
2012-07-31 01:43:00 +04:00
# include <linux/user_namespace.h>
shm: add sealing API
If two processes share a common memory region, they usually want some
guarantees to allow safe access. This often includes:
- one side cannot overwrite data while the other reads it
- one side cannot shrink the buffer while the other accesses it
- one side cannot grow the buffer beyond previously set boundaries
If there is a trust-relationship between both parties, there is no need
for policy enforcement. However, if there's no trust relationship (eg.,
for general-purpose IPC) sharing memory-regions is highly fragile and
often not possible without local copies. Look at the following two
use-cases:
1) A graphics client wants to share its rendering-buffer with a
graphics-server. The memory-region is allocated by the client for
read/write access and a second FD is passed to the server. While
scanning out from the memory region, the server has no guarantee that
the client doesn't shrink the buffer at any time, requiring rather
cumbersome SIGBUS handling.
2) A process wants to perform an RPC on another process. To avoid huge
bandwidth consumption, zero-copy is preferred. After a message is
assembled in-memory and a FD is passed to the remote side, both sides
want to be sure that neither modifies this shared copy, anymore. The
source may have put sensible data into the message without a separate
copy and the target may want to parse the message inline, to avoid a
local copy.
While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide
ways to achieve most of this, the first one is unproportionally ugly to
use in libraries and the latter two are broken/racy or even disabled due
to denial of service attacks.
This patch introduces the concept of SEALING. If you seal a file, a
specific set of operations is blocked on that file forever. Unlike locks,
seals can only be set, never removed. Hence, once you verified a specific
set of seals is set, you're guaranteed that no-one can perform the blocked
operations on this file, anymore.
An initial set of SEALS is introduced by this patch:
- SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced
in size. This affects ftruncate() and open(O_TRUNC).
- GROW: If SEAL_GROW is set, the file in question cannot be increased
in size. This affects ftruncate(), fallocate() and write().
- WRITE: If SEAL_WRITE is set, no write operations (besides resizing)
are possible. This affects fallocate(PUNCH_HOLE), mmap() and
write().
- SEAL: If SEAL_SEAL is set, no further seals can be added to a file.
This basically prevents the F_ADD_SEAL operation on a file and
can be set to prevent others from adding further seals that you
don't want.
The described use-cases can easily use these seals to provide safe use
without any trust-relationship:
1) The graphics server can verify that a passed file-descriptor has
SEAL_SHRINK set. This allows safe scanout, while the client is
allowed to increase buffer size for window-resizing on-the-fly.
Concurrent writes are explicitly allowed.
2) For general-purpose IPC, both processes can verify that SEAL_SHRINK,
SEAL_GROW and SEAL_WRITE are set. This guarantees that neither
process can modify the data while the other side parses it.
Furthermore, it guarantees that even with writable FDs passed to the
peer, it cannot increase the size to hit memory-limits of the source
process (in case the file-storage is accounted to the source).
The new API is an extension to fcntl(), adding two new commands:
F_GET_SEALS: Return a bitset describing the seals on the file. This
can be called on any FD if the underlying file supports
sealing.
F_ADD_SEALS: Change the seals of a given file. This requires WRITE
access to the file and F_SEAL_SEAL may not already be set.
Furthermore, the underlying file must support sealing and
there may not be any existing shared mapping of that file.
Otherwise, EBADF/EPERM is returned.
The given seals are _added_ to the existing set of seals
on the file. You cannot remove seals again.
The fcntl() handler is currently specific to shmem and disabled on all
files. A file needs to explicitly support sealing for this interface to
work. A separate syscall is added in a follow-up, which creates files that
support sealing. There is no intention to support this on other
file-systems. Semantics are unclear for non-volatile files and we lack any
use-case right now. Therefore, the implementation is specific to shmem.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Ryan Lortie <desrt@desrt.ca>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-09 01:25:27 +04:00
# include <linux/shmem_fs.h>
2005-04-17 02:20:36 +04:00
# include <asm/poll.h>
# include <asm/siginfo.h>
# include <asm/uaccess.h>
2009-02-02 00:26:59 +03:00
# define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | O_NOATIME)
2005-04-17 02:20:36 +04:00
static int setfl ( int fd , struct file * filp , unsigned long arg )
{
2013-01-24 02:07:38 +04:00
struct inode * inode = file_inode ( filp ) ;
2005-04-17 02:20:36 +04:00
int error = 0 ;
2006-02-03 14:04:30 +03: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-17 02:20:36 +04: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-24 02:43:26 +03:00
if ( ! inode_owner_or_capable ( inode ) )
2005-04-17 02:20:36 +04: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 ;
}
2013-09-23 00:27:52 +04:00
if ( filp - > f_op - > check_flags )
2005-04-17 02:20:36 +04:00
error = filp - > f_op - > check_flags ( arg ) ;
if ( error )
return error ;
2008-12-06 02:12:48 +03:00
/*
2009-02-02 00:26:59 +03:00
* - > fasync ( ) is responsible for setting the FASYNC bit .
2008-12-06 02:12:48 +03:00
*/
2013-09-23 00:27:52 +04:00
if ( ( ( arg ^ filp - > f_flags ) & FASYNC ) & & filp - > f_op - > fasync ) {
2009-02-02 00:26:59 +03:00
error = filp - > f_op - > fasync ( fd , filp , ( arg & FASYNC ) ! = 0 ) ;
if ( error < 0 )
goto out ;
2009-02-02 00:52:56 +03:00
if ( error > 0 )
error = 0 ;
2005-04-17 02:20:36 +04:00
}
2009-02-07 01:25:24 +03:00
spin_lock ( & filp - > f_lock ) ;
2005-04-17 02:20:36 +04:00
filp - > f_flags = ( arg & SETFL_MASK ) | ( filp - > f_flags & ~ SETFL_MASK ) ;
2009-02-07 01:25:24 +03:00
spin_unlock ( & filp - > f_lock ) ;
2009-02-02 00:26:59 +03:00
2005-04-17 02:20:36 +04:00
out :
return error ;
}
2006-10-02 13:17:15 +04:00
static void f_modown ( struct file * filp , struct pid * pid , enum pid_type type ,
2009-06-17 00:07:46 +04:00
int force )
2005-04-17 02:20:36 +04:00
{
2010-02-07 21:11:23 +03:00
write_lock_irq ( & filp - > f_owner . lock ) ;
2005-04-17 02:20:36 +04:00
if ( force | | ! filp - > f_owner . pid ) {
2006-10-02 13:17:15 +04:00
put_pid ( filp - > f_owner . pid ) ;
filp - > f_owner . pid = get_pid ( pid ) ;
filp - > f_owner . pid_type = type ;
2009-06-17 00:07:46 +04:00
if ( pid ) {
const struct cred * cred = current_cred ( ) ;
filp - > f_owner . uid = cred - > uid ;
filp - > f_owner . euid = cred - > euid ;
}
2005-04-17 02:20:36 +04:00
}
2010-02-07 21:11:23 +03:00
write_unlock_irq ( & filp - > f_owner . lock ) ;
2005-04-17 02:20:36 +04:00
}
2014-08-22 19:27:32 +04:00
void __f_setown ( struct file * filp , struct pid * pid , enum pid_type type ,
2006-10-02 13:17:15 +04:00
int force )
2005-04-17 02:20:36 +04:00
{
2014-08-22 19:27:32 +04:00
security_file_set_fowner ( filp ) ;
2009-06-17 00:07:46 +04:00
f_modown ( filp , pid , type , force ) ;
2005-04-17 02:20:36 +04:00
}
2006-10-02 13:17:15 +04:00
EXPORT_SYMBOL ( __f_setown ) ;
2005-04-17 02:20:36 +04:00
2014-08-22 19:27:32 +04:00
void f_setown ( struct file * filp , unsigned long arg , int force )
2006-10-02 13:17:15 +04:00
{
enum pid_type type ;
struct pid * pid ;
int who = arg ;
type = PIDTYPE_PID ;
if ( who < 0 ) {
type = PIDTYPE_PGID ;
who = - who ;
}
rcu_read_lock ( ) ;
2007-10-19 10:40:14 +04:00
pid = find_vpid ( who ) ;
2014-08-22 19:27:32 +04:00
__f_setown ( filp , pid , type , force ) ;
2006-10-02 13:17:15 +04:00
rcu_read_unlock ( ) ;
}
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( f_setown ) ;
void f_delown ( struct file * filp )
{
2009-06-17 00:07:46 +04:00
f_modown ( filp , NULL , PIDTYPE_PID , 1 ) ;
2006-10-02 13:17:15 +04:00
}
pid_t f_getown ( struct file * filp )
{
pid_t pid ;
2006-10-02 13:17:27 +04:00
read_lock ( & filp - > f_owner . lock ) ;
2008-02-08 15:19:20 +03:00
pid = pid_vnr ( filp - > f_owner . pid ) ;
2006-10-02 13:17:15 +04:00
if ( filp - > f_owner . pid_type = = PIDTYPE_PGID )
pid = - pid ;
2006-10-02 13:17:27 +04:00
read_unlock ( & filp - > f_owner . lock ) ;
2006-10-02 13:17:15 +04:00
return pid ;
2005-04-17 02:20:36 +04:00
}
2009-09-24 02:57:03 +04:00
static int f_setown_ex ( struct file * filp , unsigned long arg )
{
2012-09-27 05:43:05 +04:00
struct f_owner_ex __user * owner_p = ( void __user * ) arg ;
2009-09-24 02:57:03 +04: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 14:35:42 +04:00
return - EFAULT ;
2009-09-24 02:57:03 +04:00
switch ( owner . type ) {
case F_OWNER_TID :
type = PIDTYPE_MAX ;
break ;
case F_OWNER_PID :
type = PIDTYPE_PID ;
break ;
2009-11-18 01:06:24 +03:00
case F_OWNER_PGRP :
2009-09-24 02:57:03 +04:00
type = PIDTYPE_PGID ;
break ;
default :
return - EINVAL ;
}
rcu_read_lock ( ) ;
pid = find_vpid ( owner . pid ) ;
if ( owner . pid & & ! pid )
ret = - ESRCH ;
else
2014-08-22 19:27:32 +04:00
__f_setown ( filp , pid , type , 1 ) ;
2009-09-24 02:57:03 +04:00
rcu_read_unlock ( ) ;
return ret ;
}
static int f_getown_ex ( struct file * filp , unsigned long arg )
{
2012-09-27 05:43:05 +04:00
struct f_owner_ex __user * owner_p = ( void __user * ) arg ;
2009-09-24 02:57:03 +04: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-18 01:06:24 +03:00
owner . type = F_OWNER_PGRP ;
2009-09-24 02:57:03 +04:00
break ;
default :
WARN_ON ( 1 ) ;
ret = - EINVAL ;
break ;
}
read_unlock ( & filp - > f_owner . lock ) ;
2010-06-03 14:35:42 +04:00
if ( ! ret ) {
2009-09-24 02:57:03 +04:00
ret = copy_to_user ( owner_p , & owner , sizeof ( owner ) ) ;
2010-06-03 14:35:42 +04:00
if ( ret )
ret = - EFAULT ;
}
2009-09-24 02:57:03 +04:00
return ret ;
}
2012-07-31 01:43:00 +04: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-27 05:43:05 +04:00
uid_t __user * dst = ( void __user * ) arg ;
2012-07-31 01:43:00 +04: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-17 02:20:36 +04: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 19:48:11 +04: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 10:30:26 +04:00
case F_DUPFD_CLOEXEC :
2012-10-09 02:21:58 +04:00
err = f_dupfd ( arg , filp , O_CLOEXEC ) ;
2005-04-17 02:20:36 +04: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 ;
2014-02-03 21:13:10 +04:00
# if BITS_PER_LONG != 32
/* 32-bit arches must use fcntl64() */
2014-04-22 16:23:58 +04:00
case F_OFD_GETLK :
2014-02-03 21:13:10 +04:00
# endif
2005-04-17 02:20:36 +04:00
case F_GETLK :
2014-02-03 21:13:09 +04:00
err = fcntl_getlk ( filp , cmd , ( struct flock __user * ) arg ) ;
2005-04-17 02:20:36 +04:00
break ;
2014-02-03 21:13:10 +04:00
# if BITS_PER_LONG != 32
/* 32-bit arches must use fcntl64() */
2014-04-22 16:23:58 +04:00
case F_OFD_SETLK :
case F_OFD_SETLKW :
2014-02-03 21:13:10 +04:00
# endif
/* Fallthrough */
2005-04-17 02:20:36 +04:00
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 22:45:09 +04:00
err = fcntl_setlk ( fd , filp , cmd , ( struct flock __user * ) arg ) ;
2005-04-17 02:20:36 +04: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 13:17:15 +04:00
err = f_getown ( filp ) ;
2005-04-17 02:20:36 +04:00
force_successful_syscall_return ( ) ;
break ;
case F_SETOWN :
2014-08-22 19:27:32 +04:00
f_setown ( filp , arg , 1 ) ;
err = 0 ;
2005-04-17 02:20:36 +04:00
break ;
2009-09-24 02:57:03 +04: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-31 01:43:00 +04:00
case F_GETOWNER_UIDS :
err = f_getowner_uids ( filp , arg ) ;
break ;
2005-04-17 02:20:36 +04:00
case F_GETSIG :
err = filp - > f_owner . signum ;
break ;
case F_SETSIG :
/* arg == 0 restores default behaviour. */
2005-05-01 19:59:14 +04:00
if ( ! valid_signal ( arg ) ) {
2005-04-17 02:20:36 +04: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 12:43:18 +04:00
case F_SETPIPE_SZ :
case F_GETPIPE_SZ :
err = pipe_fcntl ( filp , cmd , arg ) ;
break ;
shm: add sealing API
If two processes share a common memory region, they usually want some
guarantees to allow safe access. This often includes:
- one side cannot overwrite data while the other reads it
- one side cannot shrink the buffer while the other accesses it
- one side cannot grow the buffer beyond previously set boundaries
If there is a trust-relationship between both parties, there is no need
for policy enforcement. However, if there's no trust relationship (eg.,
for general-purpose IPC) sharing memory-regions is highly fragile and
often not possible without local copies. Look at the following two
use-cases:
1) A graphics client wants to share its rendering-buffer with a
graphics-server. The memory-region is allocated by the client for
read/write access and a second FD is passed to the server. While
scanning out from the memory region, the server has no guarantee that
the client doesn't shrink the buffer at any time, requiring rather
cumbersome SIGBUS handling.
2) A process wants to perform an RPC on another process. To avoid huge
bandwidth consumption, zero-copy is preferred. After a message is
assembled in-memory and a FD is passed to the remote side, both sides
want to be sure that neither modifies this shared copy, anymore. The
source may have put sensible data into the message without a separate
copy and the target may want to parse the message inline, to avoid a
local copy.
While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide
ways to achieve most of this, the first one is unproportionally ugly to
use in libraries and the latter two are broken/racy or even disabled due
to denial of service attacks.
This patch introduces the concept of SEALING. If you seal a file, a
specific set of operations is blocked on that file forever. Unlike locks,
seals can only be set, never removed. Hence, once you verified a specific
set of seals is set, you're guaranteed that no-one can perform the blocked
operations on this file, anymore.
An initial set of SEALS is introduced by this patch:
- SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced
in size. This affects ftruncate() and open(O_TRUNC).
- GROW: If SEAL_GROW is set, the file in question cannot be increased
in size. This affects ftruncate(), fallocate() and write().
- WRITE: If SEAL_WRITE is set, no write operations (besides resizing)
are possible. This affects fallocate(PUNCH_HOLE), mmap() and
write().
- SEAL: If SEAL_SEAL is set, no further seals can be added to a file.
This basically prevents the F_ADD_SEAL operation on a file and
can be set to prevent others from adding further seals that you
don't want.
The described use-cases can easily use these seals to provide safe use
without any trust-relationship:
1) The graphics server can verify that a passed file-descriptor has
SEAL_SHRINK set. This allows safe scanout, while the client is
allowed to increase buffer size for window-resizing on-the-fly.
Concurrent writes are explicitly allowed.
2) For general-purpose IPC, both processes can verify that SEAL_SHRINK,
SEAL_GROW and SEAL_WRITE are set. This guarantees that neither
process can modify the data while the other side parses it.
Furthermore, it guarantees that even with writable FDs passed to the
peer, it cannot increase the size to hit memory-limits of the source
process (in case the file-storage is accounted to the source).
The new API is an extension to fcntl(), adding two new commands:
F_GET_SEALS: Return a bitset describing the seals on the file. This
can be called on any FD if the underlying file supports
sealing.
F_ADD_SEALS: Change the seals of a given file. This requires WRITE
access to the file and F_SEAL_SEAL may not already be set.
Furthermore, the underlying file must support sealing and
there may not be any existing shared mapping of that file.
Otherwise, EBADF/EPERM is returned.
The given seals are _added_ to the existing set of seals
on the file. You cannot remove seals again.
The fcntl() handler is currently specific to shmem and disabled on all
files. A file needs to explicitly support sealing for this interface to
work. A separate syscall is added in a follow-up, which creates files that
support sealing. There is no intention to support this on other
file-systems. Semantics are unclear for non-volatile files and we lack any
use-case right now. Therefore, the implementation is specific to shmem.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Ryan Lortie <desrt@desrt.ca>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-09 01:25:27 +04:00
case F_ADD_SEALS :
case F_GET_SEALS :
err = shmem_fcntl ( filp , cmd , arg ) ;
break ;
2005-04-17 02:20:36 +04: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 10:51:11 +03: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 16:14:17 +03:00
SYSCALL_DEFINE3 ( fcntl , unsigned int , fd , unsigned int , cmd , unsigned long , arg )
2005-04-17 02:20:36 +04:00
{
2012-08-28 20:52:22 +04:00
struct fd f = fdget_raw ( fd ) ;
2005-04-17 02:20:36 +04:00
long err = - EBADF ;
2012-08-28 20:52:22 +04:00
if ( ! f . file )
2005-04-17 02:20:36 +04:00
goto out ;
2012-08-28 20:52:22 +04:00
if ( unlikely ( f . file - > f_mode & FMODE_PATH ) ) {
2012-04-22 02:42:19 +04: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 10:51:11 +03:00
}
2012-08-28 20:52:22 +04:00
err = security_file_fcntl ( f . file , cmd , arg ) ;
2012-04-22 02:42:19 +04:00
if ( ! err )
2012-08-28 20:52:22 +04:00
err = do_fcntl ( fd , cmd , arg , f . file ) ;
2005-04-17 02:20:36 +04:00
2012-04-22 02:42:19 +04:00
out1 :
2012-08-28 20:52:22 +04:00
fdput ( f ) ;
2005-04-17 02:20:36 +04:00
out :
return err ;
}
# if BITS_PER_LONG == 32
2009-01-14 16:14:17 +03:00
SYSCALL_DEFINE3 ( fcntl64 , unsigned int , fd , unsigned int , cmd ,
unsigned long , arg )
2005-04-17 02:20:36 +04:00
{
2012-08-28 20:52:22 +04:00
struct fd f = fdget_raw ( fd ) ;
2012-04-22 02:42:19 +04:00
long err = - EBADF ;
2005-04-17 02:20:36 +04:00
2012-08-28 20:52:22 +04:00
if ( ! f . file )
2005-04-17 02:20:36 +04:00
goto out ;
2012-08-28 20:52:22 +04:00
if ( unlikely ( f . file - > f_mode & FMODE_PATH ) ) {
2012-04-22 02:42:19 +04: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 10:51:11 +03:00
}
2012-08-28 20:52:22 +04:00
err = security_file_fcntl ( f . file , cmd , arg ) ;
2012-04-22 02:42:19 +04:00
if ( err )
goto out1 ;
2005-04-17 02:20:36 +04:00
switch ( cmd ) {
2014-02-03 21:13:10 +04:00
case F_GETLK64 :
2014-04-22 16:23:58 +04:00
case F_OFD_GETLK :
2014-02-03 21:13:10 +04:00
err = fcntl_getlk64 ( f . file , cmd , ( struct flock64 __user * ) arg ) ;
break ;
case F_SETLK64 :
case F_SETLKW64 :
2014-04-22 16:23:58 +04:00
case F_OFD_SETLK :
case F_OFD_SETLKW :
2014-02-03 21:13:10 +04:00
err = fcntl_setlk64 ( fd , f . file , cmd ,
( struct flock64 __user * ) arg ) ;
break ;
default :
err = do_fcntl ( fd , cmd , arg , f . file ) ;
break ;
2005-04-17 02:20:36 +04:00
}
2012-04-22 02:42:19 +04:00
out1 :
2012-08-28 20:52:22 +04:00
fdput ( f ) ;
2005-04-17 02:20:36 +04:00
out :
return err ;
}
# endif
/* Table to convert sigio signal codes into poll band bitmaps */
2006-03-26 13:37:24 +04:00
static const long band_table [ NSIGPOLL ] = {
2005-04-17 02:20:36 +04: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-14 02:39:19 +03:00
const struct cred * cred ;
int ret ;
rcu_read_lock ( ) ;
cred = __task_cred ( p ) ;
2012-03-04 09:17:15 +04: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-14 02:39:19 +03:00
! security_file_send_sigiotask ( p , fown , sig ) ) ;
rcu_read_unlock ( ) ;
return ret ;
2005-04-17 02:20:36 +04:00
}
static void send_sigio_to_task ( struct task_struct * p ,
2009-06-17 02:27:10 +04:00
struct fown_struct * fown ,
2009-09-24 02:57:03 +04:00
int fd , int reason , int group )
2005-04-17 02:20:36 +04:00
{
2009-06-17 02:27:10 +04: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-17 02:20:36 +04:00
return ;
2009-06-17 02:27:10 +04:00
switch ( signum ) {
2005-04-17 02:20:36 +04: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-17 02:27:10 +04:00
si . si_signo = signum ;
2005-04-17 02:20:36 +04: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 15:37:19 +04:00
BUG_ON ( ( reason & __SI_MASK ) ! = __SI_POLL ) ;
2005-04-17 02:20:36 +04: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-24 02:57:03 +04:00
if ( ! do_send_sig_info ( signum , & si , p , group ) )
2005-04-17 02:20:36 +04:00
break ;
/* fall-through: fall back on the old plain SIGIO signal */
case 0 :
2009-09-24 02:57:03 +04:00
do_send_sig_info ( SIGIO , SEND_SIG_PRIV , p , group ) ;
2005-04-17 02:20:36 +04:00
}
}
void send_sigio ( struct fown_struct * fown , int fd , int band )
{
struct task_struct * p ;
2006-10-02 13:17:15 +04:00
enum pid_type type ;
struct pid * pid ;
2009-09-24 02:57:03 +04:00
int group = 1 ;
2005-04-17 02:20:36 +04:00
read_lock ( & fown - > lock ) ;
2009-09-24 02:57:03 +04:00
2006-10-02 13:17:15 +04:00
type = fown - > pid_type ;
2009-09-24 02:57:03 +04:00
if ( type = = PIDTYPE_MAX ) {
group = 0 ;
type = PIDTYPE_PID ;
}
2005-04-17 02:20:36 +04:00
pid = fown - > pid ;
if ( ! pid )
goto out_unlock_fown ;
read_lock ( & tasklist_lock ) ;
2006-10-02 13:17:15 +04:00
do_each_pid_task ( pid , type , p ) {
2009-09-24 02:57:03 +04:00
send_sigio_to_task ( p , fown , fd , band , group ) ;
2006-10-02 13:17:15 +04:00
} while_each_pid_task ( pid , type , p ) ;
2005-04-17 02:20:36 +04:00
read_unlock ( & tasklist_lock ) ;
out_unlock_fown :
read_unlock ( & fown - > lock ) ;
}
static void send_sigurg_to_task ( struct task_struct * p ,
2009-09-24 02:57:03 +04:00
struct fown_struct * fown , int group )
2005-04-17 02:20:36 +04:00
{
if ( sigio_perm ( p , fown , SIGURG ) )
2009-09-24 02:57:03 +04:00
do_send_sig_info ( SIGURG , SEND_SIG_PRIV , p , group ) ;
2005-04-17 02:20:36 +04:00
}
int send_sigurg ( struct fown_struct * fown )
{
struct task_struct * p ;
2006-10-02 13:17:15 +04:00
enum pid_type type ;
struct pid * pid ;
2009-09-24 02:57:03 +04:00
int group = 1 ;
2006-10-02 13:17:15 +04:00
int ret = 0 ;
2005-04-17 02:20:36 +04:00
read_lock ( & fown - > lock ) ;
2009-09-24 02:57:03 +04:00
2006-10-02 13:17:15 +04:00
type = fown - > pid_type ;
2009-09-24 02:57:03 +04:00
if ( type = = PIDTYPE_MAX ) {
group = 0 ;
type = PIDTYPE_PID ;
}
2005-04-17 02:20:36 +04:00
pid = fown - > pid ;
if ( ! pid )
goto out_unlock_fown ;
ret = 1 ;
read_lock ( & tasklist_lock ) ;
2006-10-02 13:17:15 +04:00
do_each_pid_task ( pid , type , p ) {
2009-09-24 02:57:03 +04:00
send_sigurg_to_task ( p , fown , group ) ;
2006-10-02 13:17:15 +04:00
} while_each_pid_task ( pid , type , p ) ;
2005-04-17 02:20:36 +04:00
read_unlock ( & tasklist_lock ) ;
out_unlock_fown :
read_unlock ( & fown - > lock ) ;
return ret ;
}
2010-04-14 13:55:35 +04:00
static DEFINE_SPINLOCK ( fasync_lock ) ;
2006-12-07 07:33:20 +03:00
static struct kmem_cache * fasync_cache __read_mostly ;
2005-04-17 02:20:36 +04:00
2010-04-14 13:55:35 +04: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-17 02:20:36 +04: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 19:23:37 +03: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-17 02:20:36 +04:00
*/
2010-10-27 20:38:12 +04:00
int fasync_remove_entry ( struct file * filp , struct fasync_struct * * fapp )
2005-04-17 02:20:36 +04: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 19:23:37 +03:00
spin_lock ( & filp - > f_lock ) ;
2010-04-14 13:55:35 +04: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 19:23:37 +03:00
for ( fp = fapp ; ( fa = * fp ) ! = NULL ; fp = & fa - > fa_next ) {
if ( fa - > fa_file ! = filp )
continue ;
2010-04-14 13:55:35 +04: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 19:23:37 +03:00
* fp = fa - > fa_next ;
2010-04-14 13:55:35 +04: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 19:23:37 +03:00
filp - > f_flags & = ~ FASYNC ;
result = 1 ;
break ;
2005-04-17 02:20:36 +04:00
}
2010-04-14 13:55:35 +04: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 19:23:37 +03:00
spin_unlock ( & filp - > f_lock ) ;
return result ;
}
2010-10-27 20:38:12 +04: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 19:23:37 +03:00
/*
2010-10-27 20:38:12 +04: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 19:23:37 +03:00
*/
2010-10-27 20:38:12 +04: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 19:23:37 +03:00
{
2010-10-27 20:38:12 +04: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 19:23:37 +03:00
2010-10-27 20:38:12 +04: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-28 05:17:02 +04:00
*
* NOTE ! It is very important that the FASYNC flag always
* match the state " is the filp on a fasync list " .
2010-10-27 20:38:12 +04: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 21:24:31 +03:00
spin_lock ( & filp - > f_lock ) ;
2010-04-14 13:55:35 +04:00
spin_lock ( & fasync_lock ) ;
2005-04-17 02:20:36 +04: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 19:23:37 +03:00
if ( fa - > fa_file ! = filp )
continue ;
2010-04-14 13:55:35 +04: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 19:23:37 +03:00
fa - > fa_fd = fd ;
2010-04-14 13:55:35 +04: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 19:23:37 +03:00
goto out ;
2005-04-17 02:20:36 +04:00
}
2010-04-14 13:55:35 +04: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 19:23:37 +03:00
new - > magic = FASYNC_MAGIC ;
new - > fa_file = filp ;
new - > fa_fd = fd ;
new - > fa_next = * fapp ;
2010-04-14 13:55:35 +04: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 19:23:37 +03:00
filp - > f_flags | = FASYNC ;
2005-04-17 02:20:36 +04:00
out :
2010-04-14 13:55:35 +04:00
spin_unlock ( & fasync_lock ) ;
2009-03-27 21:24:31 +03:00
spin_unlock ( & filp - > f_lock ) ;
2010-10-27 20:38:12 +04: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-17 02:20:36 +04: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 19:23:37 +03: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-17 02:20:36 +04:00
EXPORT_SYMBOL ( fasync_helper ) ;
2010-04-14 13:55:35 +04:00
/*
* rcu_read_lock ( ) is held
*/
static void kill_fasync_rcu ( struct fasync_struct * fa , int sig , int band )
2005-04-17 02:20:36 +04:00
{
while ( fa ) {
2010-04-14 13:55:35 +04:00
struct fown_struct * fown ;
2010-06-30 02:05:42 +04:00
unsigned long flags ;
2005-04-17 02:20:36 +04:00
if ( fa - > magic ! = FASYNC_MAGIC ) {
printk ( KERN_ERR " kill_fasync: bad magic number in "
" fasync_struct! \n " ) ;
return ;
}
2010-06-30 02:05:42 +04:00
spin_lock_irqsave ( & fa - > fa_lock , flags ) ;
2010-04-14 13:55:35 +04: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-30 02:05:42 +04:00
spin_unlock_irqrestore ( & fa - > fa_lock , flags ) ;
2010-04-14 13:55:35 +04:00
fa = rcu_dereference ( fa - > fa_next ) ;
2005-04-17 02:20:36 +04: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 13:55:35 +04:00
rcu_read_lock ( ) ;
kill_fasync_rcu ( rcu_dereference ( * fp ) , sig , band ) ;
rcu_read_unlock ( ) ;
2005-04-17 02:20:36 +04:00
}
}
EXPORT_SYMBOL ( kill_fasync ) ;
2010-08-11 05:01:29 +04:00
static int __init fcntl_init ( void )
2005-04-17 02:20:36 +04:00
{
2010-09-10 03:38:12 +04: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 .
*/
2013-07-25 04:13:19 +04:00
BUILD_BUG_ON ( 20 - 1 /* for O_RDONLY being 0 */ ! = HWEIGHT32 (
2010-08-11 05:01:29 +04:00
O_RDONLY | O_WRONLY | O_RDWR |
O_CREAT | O_EXCL | O_NOCTTY |
2010-09-10 03:38:12 +04:00
O_TRUNC | O_APPEND | /* O_NONBLOCK | */
2010-08-11 05:01:29 +04:00
__O_SYNC | O_DSYNC | FASYNC |
O_DIRECT | O_LARGEFILE | O_DIRECTORY |
O_NOFOLLOW | O_NOATIME | O_CLOEXEC |
2013-07-25 04:13:19 +04:00
__FMODE_EXEC | O_PATH | __O_TMPFILE
2010-08-11 05:01:29 +04:00
) ) ;
2005-04-17 02:20:36 +04:00
fasync_cache = kmem_cache_create ( " fasync_cache " ,
2007-07-20 05:11:58 +04:00
sizeof ( struct fasync_struct ) , 0 , SLAB_PANIC , NULL ) ;
2005-04-17 02:20:36 +04:00
return 0 ;
}
2010-08-11 05:01:29 +04:00
module_init ( fcntl_init )