linux-toradex.git/include/linux/file.h, branch v4.6-rc6

include/linux/file.h: remove get_unused_fd() macro

2014-12-11T01:41:10+00:00

Macro get_unused_fd() is used to allocate a file descriptor with default
flags.  Those default flags (0) don't enable close-on-exec.

This can be seen as an unsafe default: in most case close-on-exec should
be enabled to not leak file descriptor across exec().

It would be better to have a "safer" default set of flags, eg.  O_CLOEXEC
must be used to enable close-on-exec.

Instead this patch removes get_unused_fd() so that out of tree modules
won't be affect by a runtime behavor change which might introduce other
kind of bugs: it's better to catch the change at build time, making it
easier to fix.

Removing the macro will also promote use of get_unused_fd_flags() (or
anon_inode_getfd()) with flags provided by userspace.  Or, if flags cannot
be given by userspace, with flags set to O_CLOEXEC by default.

Signed-off-by: Yann Droneaud 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

get rid of fget_light()

2014-03-10T15:44:42+00:00

instead of returning the flags by reference, we can just have the
low-level primitive return those in lower bits of unsigned long,
with struct file * derived from the rest.

Signed-off-by: Al Viro

vfs: atomic f_pos accesses as per POSIX

2014-03-10T15:44:41+00:00

Our write() system call has always been atomic in the sense that you get
the expected thread-safe contiguous write, but we haven't actually
guaranteed that concurrent writes are serialized wrt f_pos accesses, so
threads (or processes) that share a file descriptor and use "write()"
concurrently would quite likely overwrite each others data.

This violates POSIX.1-2008/SUSv4 Section XSI 2.9.7 that says:

 "2.9.7 Thread Interactions with Regular File Operations

  All of the following functions shall be atomic with respect to each
  other in the effects specified in POSIX.1-2008 when they operate on
  regular files or symbolic links: [...]"

and one of the effects is the file position update.

This unprotected file position behavior is not new behavior, and nobody
has ever cared.  Until now.  Yongzhi Pan reported unexpected behavior to
Michael Kerrisk that was due to this.

This resolves the issue with a f_pos-specific lock that is taken by
read/write/lseek on file descriptors that may be shared across threads
or processes.

Reported-by: Yongzhi Pan 
Reported-by: Michael Kerrisk 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Al Viro

switch simple cases of fget_light to fdget

2012-09-27T02:20:08+00:00

Signed-off-by: Al Viro

new helpers: fdget()/fdput()

2012-09-27T01:16:32+00:00

Signed-off-bs: Al Viro

make expand_files() and alloc_fd() static

2012-09-27T01:09:58+00:00

no callers outside of fs/file.c left

Signed-off-by: Al Viro

new helper: replace_fd()

2012-09-27T01:09:57+00:00

analog of dup2(), except that it takes struct file * as source.

Signed-off-by: Al Viro

take purely descriptor-related stuff from fcntl.c to file.c

2012-09-27T01:09:57+00:00

Signed-off-by: Al Viro

make get_unused_fd_flags() a function

2012-09-27T01:08:50+00:00

... and get_unused_fd() a macro around it

Signed-off-by: Al Viro

switch fput to task_work_add

2012-07-22T19:57:58+00:00

... and schedule_work() for interrupt/kernel_thread callers
(and yes, now it *is* OK to call from interrupt).

We are guaranteed that __fput() will be done before we return
to userland (or exit).  Note that for fput() from a kernel
thread we get an async behaviour; it's almost always OK, but
sometimes you might need to have __fput() completed before
you do anything else.  There are two mechanisms for that -
a general barrier (flush_delayed_fput()) and explicit
__fput_sync().  Both should be used with care (as was the
case for fput() from kernel threads all along).  See comments
in fs/file_table.c for details.

Signed-off-by: Al Viro