[lkml]   [2002]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BKL removal from VFS

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.043 / U:23.404 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site