Re: [PATCH -tip] remove the BKL: Replace BKL in mount/umountsyscalls with a mutex

From: Ingo Molnar
Date: Thu Apr 16 2009 - 13:14:25 EST



* Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

> On Thu, Apr 16, 2009 at 06:49:27PM +0200, Ingo Molnar wrote:
>
> > They dont really protect anything - the patch is wrong and
> > equivalent to a plain removal of the BKL.
> >
> > The only case we found to ever matter in practice is NFS: it
> > really wants to get rid of the BKL in nfsd_get_sb(). So pushing
> > down the BKL lock into per filesystems and then removing it from
> > NFS should do the trick.
> >
> > Would be nice to have some tentative Ack (or, a tentative
> > non-immediate-NAK) from Al before we go touch a lot of
> > filesystems though. Stupid dont-waste-human-effort
> > considerations and stuff.
> >
> > For us, the much simpler solution would be to drop the BKL in
> > nfsd_get_sb() and go on with life without to touch a dozen or so
> > filesystems. Alessio, mind trying that too, is it a solution for
> > your testcase?
>
> What about trying to attack it piece-mail? ->unmount_begin is
> really easy. The only one that doesn't protect everything
> properly is 9p, but it doesn't protect the state variable deep
> down a few levels of function calls at all.
>
> ->remount_fs should be easy enough to, we do have proper per-sb
> protection here, but do_remount_sb will need a bit of an audit.
> (and of course pushing lock_kernel down into the many instances
> and leave the cleanup-work to the fs maintainers).
>
> The actual mount path is more interesting as there are quite a few
> cases there. As a first step you can take lock_kernel from
> outside do_mount into the various do_foo calls inside it, and then
> work on those piece by piece.

We'd be glad to - but only with full principle and workflow backing
of VFS-folks. This has been going on for more than a year - with
ancient commits in tip:core/kill-the-BKL. I cannot mix stuff into it
that gets eventual hostile treatment and NAKs a few months down the
line, should this be submitted upstream.

Ingo
--
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/