[PATCH/RFC] F_SETFL/Fasync BKL removal, now without unsightly global locks

[Jonathan Corbet]

Here is yet another attempt to remove the BKL from the handling of changes
to filp->f_flags and FASYNC changes.  This approach is a bit more complex,
and has been split into four patches.  The end-result is the removal of the
BKL and some excess code.

1) Use bitops for f_flags: turn f_flags into an unsigned long and
   manipulate its contents with atomic bitops.  New NR_* macros have been
   defined for the bits which are actually changed after open/create time.

2) Use a bitlock in epoll: use one of the f_flags bit to replace the
   ep_lock spinlock.  This (more than) mitigates the growth in struct file
   created by part 1).  The bitop will be a bit slower, but it should not
   be a performance-critical part of the epoll implementation.  (Ideal
   courtesy of Matt Mackall).

3) Move FASYNC bit handling into ->fasync(): this is how changes to that
   bit and calls to f_op->fasync() are kept atomic in the absence of the
   BKL.  Almost every FASYNC implementation uses fasync_helper(), so the
   actual bit manipulation is done there.  The one exception (for sockets)
   has been fixed up.  At this point, there is no more BKL in these paths.
   (Idea-suggested-by: Andi Kleen).

4) Rationalize fasync_helper() return value handling.  Some drivers mapped
   positive return values from fasync_helper() onto zero, most others did
   not bother.  This optional cleanup patch moves that mapping into the VFS
   code, making things consistent and enabling the removal of some 50 lines
   of code.  It's worth noting that this is technically an ABI change: some
   drivers which returned positive values from fcntl(..., F_SETFL, ...)
   will now return zero instead.  I sure *hope* that wouldn't break
   anything... 

To be extra-sure that I wasn't breaking anything subtle, I went and figured
out how to run the Linux Test Project suite.  Pretty amazing stuff - I've
never run a program which would put my system's load average at 7400
before.  If there are any regressions here, LTP did not find them.

As always, comments welcome.

jon


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/