Re: BKL removal from VFS
Steve Lord (firstname.lastname@example.org)
19 Feb 2002 10:19:11 -0600
On Tue, 2002-02-19 at 10:11, Alexander Viro wrote:
> On 19 Feb 2002, Steve Lord wrote:
> > Al, I am not proposing this to go in, but what is your opinion on a
> > change like this? XFS does not need the BKL at all, so for some aim7
> > experiments on large systems this patch was used to bypass the BKL for
> > filesystems which state they can live without it:
> > +#define lock_kernel_optional(ip) \
> > + if (!(ip->i_flags & S_NOBKL)) lock_kernel()
> > +
> Denied. No way in hell that (or similar) will ever go in. Locking must
> be consistent, _period_. No provisions for "legacy drivers" and crap
> like that - it's a standard policy in all kernel and that had been discussed
> a lot of times.
> _Please_, check 2.5. We already don't take BKL on majority of directory
> operations. The rest will follow pretty soon.
> In particular, in current Linus' tree there are 3 (three) instances of
> lock_kernel() in fs/namei.c. Namely, ->permission() and two calls of
> d_move(). The latter will go when ->d_parent mess is cleaned up. The
> former will go as soon as we get to ->setattr()/->permission() cleanups -
> hopefully in a week or so.
> In general, such changes are done by global lock shifting - simultaneous
> for all instances and being a trivial search-and-replace. Once the lock
> is taken inside the method individual filesystems/drivers/etc. can
> shrink the protected areas - in separate patches.
> That's how it works - and that's how it had been done for most of the methods
> already. Magic flags that make locking different for different instances
> are Not Good. And not needed - see above for the usual way to do that stuff.
Whoa, light blue touch paper and stand back! Like I said I was not proposing
this to go into the kernel, just asking your opinion. Yes I am aware of the
changes going into locking in 2.5 and like the way things are going there,
XFS is ticking along quite happily in 2.5.5-pre1 here.
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: email@example.com
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/