Messages in this thread | | | Date | Wed, 31 Mar 2010 23:56:25 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 6/6] procfs: Kill the bkl in ioctl |
| |
On Wed, Mar 31, 2010 at 11:04:30PM +0200, Arnd Bergmann wrote: > On Wednesday 31 March 2010 22:21:23 Arnd Bergmann wrote: > > Another crazy idea I had was to simply turn the BKL into a regular mutex > > as soon as we can show that all remaining users are of the non-recursive > > kind and don't rely on the autorelease-on-sleep. Doing that would be > > much easier without the pushdown into .unlocked_ioctl than it would be > > with it. > > I just looked at all the users of lock_kernel remaining with my patch > series. For 90% of them, it is completely obvious that they don't rely > on nested locking, and they very much look like they don't need the > autorelease either, because the BKL was simply pushed down into the > open, ioctl and llseek functions. > > There are a few file systems (udf, ncpfs, autofs, coda, ...) and some > network protocols (appletalk, ipx, irnet and x25) for which it is not > obviously, though still quite likely, the case. > > So we could actually remove the BKL recursion code soon, or even turn > all of it into a regular mutex, at least as an experimental option. > > The recursive users that I've removed in my series are the block, tty, > input and sound subsystems, as well as the init code.
This is a solution that has been tried more than once already. But Linus has told he wouldn't pull something that turns the bkl into a mutex or a semaphore.
Plus it's quite hard to tell that it does or not auto-release somewhere This is often something you can really spot on runtime or on small path only.
The simple fact the bkl is not always a leaf lock makes it need the auto-release, otherwise you experience very bad unexpected lock dependencies.
| |