pm24.git/include/linux/fdtable.h, branch v3.7-rc8

new helper: daemonize_descriptors()

2012-09-27T01:10:00Z

descriptor-related parts of daemonize, done right. As the result we simplify the locking rules for ->files - we hold task_lock in *all* cases when we modify ->files. Signed-off-by: Al Viro

new helper: iterate_fd()

2012-09-27T01:09:59Z

iterates through the opened files in given descriptor table, calling a supplied function; we stop once non-zero is returned. Callback gets struct file *, descriptor number and const void * argument passed to iterator. It is called with files->file_lock held, so it is not allowed to block. tty_io, netprio_cgroup and selinux flush_unauthorized_files() converted to its use. Signed-off-by: Al Viro

make expand_files() and alloc_fd() static

2012-09-27T01:09:58Z

no callers outside of fs/file.c left Signed-off-by: Al Viro

take __{set,clear}_{open_fd,close_on_exec}() into fs/file.c

2012-09-27T01:09:58Z

nobody uses those outside anymore. Signed-off-by: Al Viro

take close-on-exec logics to fs/file.c, clean it up a bit

2012-09-27T01:09:56Z

... and add cond_resched() there, while we are at it. We can get large latencies as is... Signed-off-by: Al Viro

take descriptor-related part of close() to file.c

2012-09-27T01:08:56Z

Signed-off-by: Al Viro

expose a low-level variant of fd_install() for binder

2012-09-27T01:08:55Z

Similar situation to that of __alloc_fd(); do not use unless you really have to. You should not touch any descriptor table other than your own; it's a sure sign of a really bad API design. As with __alloc_fd(), you *must* use a first-class reference to struct files_struct; something obtained by get_files_struct(some task) (let alone direct task->files) will not do. It must be either current->files, or obtained by get_files_struct(current) by the owner of that sucker and given to you. Signed-off-by: Al Viro

move files_struct-related bits from kernel/exit.c to fs/file.c

2012-09-27T01:08:54Z

Signed-off-by: Al Viro

new helper: __alloc_fd()

2012-09-27T01:08:53Z

Essentially, alloc_fd() in a files_struct we own a reference to. Most of the time wanting to use it is a sign of lousy API design (such as android/binder). It's *not* a general-purpose interface; better that than open-coding its guts, but again, playing with other process' descriptor table is a sign of bad design. Signed-off-by: Al Viro

Replace the fd_sets in struct fdtable with an array of unsigned longs

2012-02-19T18:30:57Z

Replace the fd_sets in struct fdtable with an array of unsigned longs and then use the standard non-atomic bit operations rather than the FD_* macros. This: (1) Removes the abuses of struct fd_set: (a) Since we don't want to allocate a full fd_set the vast majority of the time, we actually, in effect, just allocate a just-big-enough array of unsigned longs and cast it to an fd_set type - so why bother with the fd_set at all? (b) Some places outside of the core fdtable handling code (such as SELinux) want to look inside the array of unsigned longs hidden inside the fd_set struct for more efficient iteration over the entire set. (2) Eliminates the use of FD_*() macros in the kernel completely. (3) Permits the __FD_*() macros to be deleted entirely where not exposed to userspace. Signed-off-by: David Howells Link: http://lkml.kernel.org/r/20120216174954.23314.48147.stgit@warthog.procyon.org.uk Signed-off-by: H. Peter Anvin Cc: Al Viro