|author||Jonathan Corbet <firstname.lastname@example.org>||2009-02-01 14:26:59 -0700|
|committer||Jonathan Corbet <email@example.com>||2009-03-16 08:32:27 -0600|
Move FASYNC bit handling to f_op->fasync()
Removing the BKL from FASYNC handling ran into the challenge of keeping the setting of the FASYNC bit in filp->f_flags atomic with regard to calls to the underlying fasync() function. Andi Kleen suggested moving the handling of that bit into fasync(); this patch does exactly that. As a result, we have a couple of internal API changes: fasync() must now manage the FASYNC bit, and it will be called without the BKL held. As it happens, every fasync() implementation in the kernel with one exception calls fasync_helper(). So, if we make fasync_helper() set the FASYNC bit, we can avoid making any changes to the other fasync() functions - as long as those functions, themselves, have proper locking. Most fasync() implementations do nothing but call fasync_helper() - which has its own lock - so they are easily verified as correct. The BKL had already been pushed down into the rest. The networking code has its own version of fasync_helper(), so that code has been augmented with explicit FASYNC bit handling. Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: David Miller <firstname.lastname@example.org> Reviewed-by: Christoph Hellwig <email@example.com> Signed-off-by: Jonathan Corbet <firstname.lastname@example.org>
Diffstat (limited to 'Documentation')
1 files changed, 5 insertions, 2 deletions
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index ec6a9392a17..4e78ce67784 100644
@@ -437,8 +437,11 @@ grab BKL for cases when we close a file that had been opened r/w, but that
can and should be done using the internal locking with smaller critical areas).
Current worst offender is ext2_get_block()...
-->fasync() is a mess. This area needs a big cleanup and that will probably
+->fasync() is called without BKL protection, and is responsible for
+maintaining the FASYNC bit in filp->f_flags. Most instances call
+fasync_helper(), which does that maintenance, so it's not normally
+something one needs to worry about. Return values > 0 will be mapped to
+zero in the VFS layer.
->readdir() and ->ioctl() on directories must be changed. Ideally we would
move ->readdir() to inode_operations and use a separate method for directory