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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
