Why does ext4_fill_super release the BKL on entry and take it on both
normal and abnormal exit? As far as I can see, ext4_fill_super is called
by get_sb_bdev, which calls the ->get_sb method without the BKL, and
ext4_get_sb calls get_sb_bdev without the BKL. And the ext2 code does not
touch the BKL in ext2_fill_super.
Is the VFS code going to be changed somewhere in the future and it's being
anticipated, or is this a bug?
On Wed, 2007-04-04 at 08:57 -0400, John Anthony Kazos Jr. wrote:
> Why does ext4_fill_super release the BKL on entry and take it on both
> normal and abnormal exit? As far as I can see, ext4_fill_super is called
> by get_sb_bdev, which calls the ->get_sb method without the BKL, and
> ext4_get_sb calls get_sb_bdev without the BKL. And the ext2 code does not
> touch the BKL in ext2_fill_super.
>
> Is the VFS code going to be changed somewhere in the future and it's being
> anticipated, or is this a bug?
According to Documentation/filesystems/Locking, ->get_sb() is called
with the BKL held, but looking through the code, I'm not able to find
where it is being taken.
Shaggy
--
David Kleikamp
IBM Linux Technology Center
> According to Documentation/filesystems/Locking, ->get_sb() is called
> with the BKL held, but looking through the code, I'm not able to find
> where it is being taken.
I noticed that too. Unless I'm just dumb and can't see it, I'm not able to
find any BKL references during filesystem mounting until you get into
FS-specific code. I looked through everything from sys_mount through to
vfs_kern_mount. Documentation/filesystems/porting talks about several
situations where the VFS code was modified to not take the BKL, and BLK
calls were added by FS non-maintainers for safety until each FS could be
audited independently, but that wouldn't be the case, would it?
The ext2 code takes the BKL in three places: ext2_update_inode,
write_super, and ext2_compat_ioctl. Starting with ext3, it's in
ext3_compat_ioctl and ext3_fill_super, and the same with ext4.
I suppose the BKL does have to be held, somehow, somewhere, during
mounting, or anybody using ext3 on a multiprocessor box would lock their
system from unmatched locking calls. Unless the first unlock_kernel()
would make the count -1 and the lock would bring it back to zero?
On Wed, 2007-04-04 at 12:52 -0400, John Anthony Kazos Jr. wrote:
> > According to Documentation/filesystems/Locking, ->get_sb() is called
> > with the BKL held, but looking through the code, I'm not able to find
> > where it is being taken.
>
> I noticed that too. Unless I'm just dumb and can't see it, I'm not able to
> find any BKL references during filesystem mounting until you get into
> FS-specific code. I looked through everything from sys_mount through to
> vfs_kern_mount. Documentation/filesystems/porting talks about several
> situations where the VFS code was modified to not take the BKL, and BLK
> calls were added by FS non-maintainers for safety until each FS could be
> audited independently, but that wouldn't be the case, would it?
sys_mount->do_mount->do_new_mount->do_kern_mount path
part of sys_mount()
1570 goto out3;
1571
1572 lock_kernel();
1573 retval = do_mount((char *)dev_page, dir_page, (char *)type_page,
1574 flags, (void *)data_page);
1575 unlock_kernel();
1576 free_page(data_page);
1577
1578 out3:
1579 free_page(dev_page)
;
>
> The ext2 code takes the BKL in three places: ext2_update_inode,
> write_super, and ext2_compat_ioctl. Starting with ext3, it's in
> ext3_compat_ioctl and ext3_fill_super, and the same with ext4.
>
> I suppose the BKL does have to be held, somehow, somewhere, during
> mounting, or anybody using ext3 on a multiprocessor box would lock their
> system from unmatched locking calls. Unless the first unlock_kernel()
> would make the count -1 and the lock would bring it back to zero?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2007-04-10 at 12:03 -0400, Ming Zhang wrote:
> On Wed, 2007-04-04 at 12:52 -0400, John Anthony Kazos Jr. wrote:
> > > According to Documentation/filesystems/Locking, ->get_sb() is called
> > > with the BKL held, but looking through the code, I'm not able to find
> > > where it is being taken.
> >
> > I noticed that too. Unless I'm just dumb and can't see it, I'm not able to
> > find any BKL references during filesystem mounting until you get into
> > FS-specific code. I looked through everything from sys_mount through to
> > vfs_kern_mount. Documentation/filesystems/porting talks about several
> > situations where the VFS code was modified to not take the BKL, and BLK
> > calls were added by FS non-maintainers for safety until each FS could be
> > audited independently, but that wouldn't be the case, would it?
>
>
> sys_mount->do_mount->do_new_mount->do_kern_mount path
>
> part of sys_mount()
>
> 1570 goto out3;
> 1571
> 1572 lock_kernel();
> 1573 retval = do_mount((char *)dev_page, dir_page, (char *)type_page,
> 1574 flags, (void *)data_page);
> 1575 unlock_kernel();
> 1576 free_page(data_page);
> 1577
> 1578 out3:
> 1579 free_page(dev_page)
Thanks. I missed that somehow. It seems the documentation is correct.
--
David Kleikamp
IBM Linux Technology Center
On Tue, 2007-04-10 at 11:10 -0500, Dave Kleikamp wrote:
> On Tue, 2007-04-10 at 12:03 -0400, Ming Zhang wrote:
> > On Wed, 2007-04-04 at 12:52 -0400, John Anthony Kazos Jr. wrote:
> > > > According to Documentation/filesystems/Locking, ->get_sb() is called
> > > > with the BKL held, but looking through the code, I'm not able to find
> > > > where it is being taken.
> > >
> > > I noticed that too. Unless I'm just dumb and can't see it, I'm not able to
> > > find any BKL references during filesystem mounting until you get into
> > > FS-specific code. I looked through everything from sys_mount through to
> > > vfs_kern_mount. Documentation/filesystems/porting talks about several
> > > situations where the VFS code was modified to not take the BKL, and BLK
> > > calls were added by FS non-maintainers for safety until each FS could be
> > > audited independently, but that wouldn't be the case, would it?
> >
> >
> > sys_mount->do_mount->do_new_mount->do_kern_mount path
> >
> > part of sys_mount()
> >
> > 1570 goto out3;
> > 1571
> > 1572 lock_kernel();
> > 1573 retval = do_mount((char *)dev_page, dir_page, (char *)type_page,
> > 1574 flags, (void *)data_page);
> > 1575 unlock_kernel();
> > 1576 free_page(data_page);
> > 1577
> > 1578 out3:
> > 1579 free_page(dev_page)
>
> Thanks. I missed that somehow. It seems the documentation is correct.
welcome. i last time spend 30 minutes on finding it, so i pinned this
piece of info in my brain memory...