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

Jonathan Corbet
2009-02-02T18:20:30Z

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