Very Computer

by **Richard Gooc** » Tue, 02 Apr 2002 05:20:09

Hi, Al. I've noticed that you've made changes to the locking rules
for the VFS (for example, the inode lookup() method no longer has the
BKL).

I also note that you've thrown calls to lock_kernel() and
unlock_kernel() into the devfs code. Did you check each place you
added the BKL to devfs that it was needed, or was this just a blind
global operation? At first glance, it appears that many of the places
where the BKL was inserted are not needed.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Alexander Vir** » Tue, 02 Apr 2002 06:10:08

> Hi, Al. I've noticed that you've made changes to the locking rules
> for the VFS (for example, the inode lookup() method no longer has the
> BKL).

> I also note that you've thrown calls to lock_kernel() and
> unlock_kernel() into the devfs code. Did you check each place you
> added the BKL to devfs that it was needed, or was this just a blind
> global operation? At first glance, it appears that many of the places
> where the BKL was inserted are not needed.

See Documentation/filesystems/porting

BKL had been shifted inside several methods, so that filesystem code itself
had the same locking as it used to (i.e. code that used to be under BKL
stayed under it). If your code doesn't need BKL - feel free to shrink the
area, but keep in mind that it used to be under BKL.

I didn't _add_ BKL - neither in devfs nor anywhere else. lock_kernel() is
the boundary of the protected area and all that had happened is that this
area had slightly shrunken, so its boundaries are inside the method instead
of being around its caller.

Again, further shrinking is up to maintainers of the filesystems.

While we are at it, the changes in question had happened quite a couple
of months ago - none of them in 2.5.7...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Richard Gooc** » Tue, 02 Apr 2002 06:10:08

Alexander Viro writes:

> > Hi, Al. I've noticed that you've made changes to the locking rules
> > for the VFS (for example, the inode lookup() method no longer has the
> > BKL).

> > I also note that you've thrown calls to lock_kernel() and
> > unlock_kernel() into the devfs code. Did you check each place you
> > added the BKL to devfs that it was needed, or was this just a blind
> > global operation? At first glance, it appears that many of the places
> > where the BKL was inserted are not needed.

> See Documentation/filesystems/porting

Ah. Useful.

Quote:> BKL had been shifted inside several methods, so that filesystem code
> itself had the same locking as it used to (i.e. code that used to be
> under BKL stayed under it). If your code doesn't need BKL - feel
> free to shrink the area, but keep in mind that it used to be under
> BKL.

OK, that's what I figured. Thanks for the confirmation.

Quote:> I didn't _add_ BKL - neither in devfs nor anywhere else. lock_kernel() is
> the boundary of the protected area and all that had happened is that this
> area had slightly shrunken, so its boundaries are inside the method instead
> of being around its caller.

> Again, further shrinking is up to maintainers of the filesystems.

Fair enough. I'll start looking at that.

Quote:> While we are at it, the changes in question had happened quite a
> couple of months ago - none of them in 2.5.7...

Well, 2.5.7 is the first I've checked in a while: I've been mostly
focussed on 2.4.x recently.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Very Computer

VFS locking changes in 2.5.7

VFS locking changes in 2.5.7

VFS locking changes in 2.5.7

VFS locking changes in 2.5.7