1. 04 Oct, 2010 19 commits
    • Arnd Bergmann's avatar
      BKL: Remove BKL from afs · 77f2fe03
      Arnd Bergmann authored
      The BKL is only used in put_super and fill_super, which are both protected
      by the superblocks s_umount rw_semaphore. Therefore it is safe to remove
      the BKL entirely.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: linux-afs@lists.infradead.org
      Cc: David Howells <dhowells@redhat.com>
      77f2fe03
    • Arnd Bergmann's avatar
      BKL: Remove BKL from USB gadgetfs · cdbd2b01
      Arnd Bergmann authored
      The BKL is only used in fill_super, which is  protected by the superblocks
      s_umount rw_semaphore. Therefore it is safe to remove the BKL entirely.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: linux-usb@vger.kernel.org
      cdbd2b01
    • Arnd Bergmann's avatar
      BKL: Remove BKL from autofs4 · 00e300e1
      Arnd Bergmann authored
      autofs4 uses the BKL only to guard its ioctl operations.
      This can be trivially converted to use a mutex, as we have
      done with most device drivers before.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ian Kent <raven@themaw.net>
      00e300e1
    • Arnd Bergmann's avatar
      BKL: Remove BKL from isofs · 4f819a78
      Arnd Bergmann authored
      As in other file systems, we can replace the big kernel lock
      with a private mutex in isofs. This means we can now access
      multiple file systems concurrently, but it also means that
      we serialize readdir and lookup across sleeping operations
      which previously released the big kernel lock. This should
      not matter though, as these operations are in practice
      serialized through the hardware access.
      
      The isofs_get_blocks functions now does not take any lock
      any more, it used to recursively get the BKL. After looking
      at the code for hours, I convinced myself that it was never
      needed here anyway, because it only reads constant fields
      of the inode and writes to a buffer head array that is
      at this time only visible to the caller.
      
      The get_sb and fill_super operations do not need the locking
      at all because they operate on a file system that is either
      about to be created or to be destroyed but in either case
      is not visible to other threads.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      4f819a78
    • Arnd Bergmann's avatar
      BKL: Remove BKL from fat · 3768744c
      Arnd Bergmann authored
      The lock_kernel in fat_put_super is not needed because
      it only protects the super block itself and we know that
      no other thread can reach it because we are about to
      kfree the object.
      
      In the two fill_super functions, this converts the locking
      to use lock_super like elsewhere in the fat code. This
      is probably not needed either, but is consistent and puts
      us on the safe side.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Jan Blunck <jblunck@infradead.org>
      3768744c
    • Jan Blunck's avatar
      BKL: Remove BKL from ext2 filesystem · 3e44f9f1
      Jan Blunck authored
      The BKL is still used in ext2_put_super(), ext2_fill_super(), ext2_sync_fs()
      ext2_remount() and ext2_write_inode(). From these calls ext2_put_super(),
      ext2_fill_super() and ext2_remount() are protected against each other by
      the struct super_block s_umount rw semaphore. The call in ext2_write_inode()
      could only protect the modification of the ext2_sb_info through
      ext2_update_dynamic_rev() against concurrent ext2_sync_fs() or ext2_remount().
      ext2_fill_super() and ext2_put_super() can be left out because you need a
      valid filesystem reference in all three cases, which you do not have when
      you are one of these functions.
      
      If the BKL is only protecting the modification of the ext2_sb_info it can
      safely be removed since this is protected by the struct ext2_sb_info s_lock.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      3e44f9f1
    • Jan Blunck's avatar
      BKL: Remove BKL from do_new_mount() · 6841c050
      Jan Blunck authored
      After pushing down the BKL to the get_sb/fill_super operations of the
      filesystems that still make usage of the BKL it is safe to remove it from
      do_new_mount().
      
      I've read through all the code formerly covered by the BKL inside
      do_kern_mount() and have satisfied myself that it doesn't need the BKL
      any more.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      6841c050
    • Jan Blunck's avatar
      BKL: Remove BKL from cgroup · 38d018db
      Jan Blunck authored
      The BKL is only used in remount_fs and get_sb that are both protected by
      the superblocks s_umount rw_semaphore. Therefore it is safe to remove the
      BKL entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      38d018db
    • Jan Blunck's avatar
      BKL: Remove BKL from NTFS · efdffb54
      Jan Blunck authored
      The BKL is only used in put_super, fill_super and remount_fs that are all
      three protected by the superblocks s_umount rw_semaphore. Therefore it is
      safe to remove the BKL entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      efdffb54
    • Jan Blunck's avatar
      BKL: Remove BKL from NILFS2 · d6d4c19c
      Jan Blunck authored
      The BKL is only used in put_super, fill_super and remount_fs that are all
      three protected by the superblocks s_umount rw_semaphore. Therefore it is
      safe to remove the BKL entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d6d4c19c
    • Jan Blunck's avatar
      BKL: Remove BKL from JFS · 22b26db6
      Jan Blunck authored
      The BKL is only used in put_super, fill_super and remount_fs that are all
      three protected by the superblocks s_umount rw_semaphore. Therefore it is
      safe to remove the BKL entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      22b26db6
    • Jan Blunck's avatar
      BKL: Remove BKL from HFS · 8526fb37
      Jan Blunck authored
      The BKL is only used in put_super and fill_super that are both protected by
      the superblocks s_umount rw_semaphore. Therefore it is safe to remove the
      BKL entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      8526fb37
    • Jan Blunck's avatar
      BKL: Remove BKL from ext4 filesystem · f2143c4e
      Jan Blunck authored
      The BKL is still used in ext4_put_super(), ext4_fill_super() and
      ext4_remount(). All three calles are protected against concurrent calls by
      the s_umount rw semaphore of struct super_block.
      
      Therefore the BKL is protecting nothing in this case.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Acked-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      f2143c4e
    • Jan Blunck's avatar
      BKL: Remove BKL from ext3_put_super() and ext3_remount() · 77b54a46
      Jan Blunck authored
      The BKL lock is protecting the remounting against a potential call to
      ext3_put_super(). This could not happen, since this is protected by the
      s_umount rw semaphore of struct super_block.
      
      Therefore I think the BKL is protecting nothing here.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      77b54a46
    • Jan Blunck's avatar
      BKL: Remove BKL from ext3 fill_super() · d646cf82
      Jan Blunck authored
      The BKL is protecting nothing than two memory allocations here.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d646cf82
    • Jan Blunck's avatar
      BKL: Remove BKL from CifsFS · b0991aa3
      Jan Blunck authored
      The BKL is only used in put_super and fill_super that are both protected by
      the superblocks s_umount rw_semaphore. Therefore it is safe to remove the
      BKL entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Cc: Steve French <smfrench@gmail.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      b0991aa3
    • Jan Blunck's avatar
      BKL: Remove BKL from BFS · ba13d597
      Jan Blunck authored
      The BKL is only used in put_super and fill_super that are both protected by
      the superblocks s_umount rw_semaphore. Therefore it is safe to remove the BKL
      entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      ba13d597
    • Jan Blunck's avatar
      BKL: Remove BKL from Amiga FFS · 74c41429
      Jan Blunck authored
      The BKL is only used in put_super, fill_super and remount_fs that are all
      three protected by the superblocks s_umount rw_semaphore. Therefore it is
      safe to remove the BKL entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      74c41429
    • Jan Blunck's avatar
      BKL: Explicitly add BKL around get_sb/fill_super · db719222
      Jan Blunck authored
      This patch is a preparation necessary to remove the BKL from do_new_mount().
      It explicitly adds calls to lock_kernel()/unlock_kernel() around
      get_sb/fill_super operations for filesystems that still uses the BKL.
      
      I've read through all the code formerly covered by the BKL inside
      do_kern_mount() and have satisfied myself that it doesn't need the BKL
      any more.
      
      do_kern_mount() is already called without the BKL when mounting the rootfs
      and in nfsctl. do_kern_mount() calls vfs_kern_mount(), which is called
      from various places without BKL: simple_pin_fs(), nfs_do_clone_mount()
      through nfs_follow_mountpoint(), afs_mntpt_do_automount() through
      afs_mntpt_follow_link(). Both later functions are actually the filesystems
      follow_link inode operation. vfs_kern_mount() is calling the specified
      get_sb function and lets the filesystem do its job by calling the given
      fill_super function.
      
      Therefore I think it is safe to push down the BKL from the VFS to the
      low-level filesystems get_sb/fill_super operation.
      
      [arnd: do not add the BKL to those file systems that already
             don't use it elsewhere]
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Christoph Hellwig <hch@infradead.org>
      db719222
  2. 29 Sep, 2010 2 commits
  3. 28 Sep, 2010 9 commits
  4. 27 Sep, 2010 10 commits