1. 22 10月, 2010 1 次提交
  2. 21 10月, 2010 1 次提交
    • S
      cifs: convert cifs_tcp_ses_lock from a rwlock to a spinlock · 3f9bcca7
      Suresh Jayaraman 提交于
      cifs_tcp_ses_lock is a rwlock with protects the cifs_tcp_ses_list,
      server->smb_ses_list and the ses->tcon_list. It also protects a few
      ref counters in server, ses and tcon. In most cases the critical section
      doesn't seem to be large, in a few cases where it is slightly large, there
      seem to be really no benefit from concurrent access. I briefly considered RCU
      mechanism but it appears to me that there is no real need.
      
      Replace it with a spinlock and get rid of the last rwlock in the cifs code.
      Signed-off-by: NSuresh Jayaraman <sjayaraman@suse.de>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      3f9bcca7
  3. 20 10月, 2010 2 次提交
  4. 18 10月, 2010 10 次提交
  5. 16 10月, 2010 1 次提交
  6. 15 10月, 2010 2 次提交
  7. 13 10月, 2010 2 次提交
    • J
      cifs: don't use vfsmount to pin superblock for oplock breaks · d7c86ff8
      Jeff Layton 提交于
      Filesystems aren't really supposed to do anything with a vfsmount. It's
      considered a layering violation since vfsmounts are entirely managed at
      the VFS layer.
      
      CIFS currently keeps an active reference to a vfsmount in order to
      prevent the superblock vanishing before an oplock break has completed.
      What we really want to do instead is to keep sb->s_active high until the
      oplock break has completed. This patch borrows the scheme that NFS uses
      for handling sillyrenames.
      
      An atomic_t is added to the cifs_sb_info. When it transitions from 0 to
      1, an extra reference to the superblock is taken (by bumping the
      s_active value). When it transitions from 1 to 0, that reference is
      dropped and a the superblock teardown may proceed if there are no more
      references to it.
      
      Also, the vfsmount pointer is removed from cifsFileInfo and from
      cifs_new_fileinfo, and some bogus forward declarations are removed from
      cifsfs.h.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NSuresh Jayaraman <sjayaraman@suse.de>
      Acked-by: NDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      d7c86ff8
    • J
      cifs: keep dentry reference in cifsFileInfo instead of inode reference · a5e18bc3
      Jeff Layton 提交于
      cifsFileInfo is a bit problematic. It contains a reference back to the
      struct file itself. This makes it difficult for a cifsFileInfo to exist
      without a corresponding struct file.
      
      It would be better instead of the cifsFileInfo just held info pertaining
      to the open file on the server instead without any back refrences to the
      struct file. This would allow it to exist after the filp to which it was
      originally attached was closed.
      
      Much of the use of the file pointer in this struct is to get at the
      dentry.  Begin divorcing the cifsFileInfo from the struct file by
      keeping a reference to the dentry. Since the dentry will have a
      reference to the inode, we can eliminate the "pInode" field too and
      convert the igrab/iput to dget/dput.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NSuresh Jayaraman <sjayaraman@suse.de>
      Acked-by: NDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      a5e18bc3
  8. 12 10月, 2010 2 次提交
  9. 09 10月, 2010 1 次提交
  10. 08 10月, 2010 7 次提交
  11. 07 10月, 2010 5 次提交
  12. 05 10月, 2010 3 次提交
    • A
      fs/locks.c: prepare for BKL removal · b89f4321
      Arnd Bergmann 提交于
      This prepares the removal of the big kernel lock from the
      file locking code. We still use the BKL as long as fs/lockd
      uses it and ceph might sleep, but we can flip the definition
      to a private spinlock as soon as that's done.
      All users outside of fs/lockd get converted to use
      lock_flocks() instead of lock_kernel() where appropriate.
      
      Based on an earlier patch to use a spinlock from Matthew
      Wilcox, who has attempted this a few times before, the
      earliest patch from over 10 years ago turned it into
      a semaphore, which ended up being slower than the BKL
      and was subsequently reverted.
      
      Someone should do some serious performance testing when
      this becomes a spinlock, since this has caused problems
      before. Using a spinlock should be at least as good
      as the BKL in theory, but who knows...
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMatthew Wilcox <willy@linux.intel.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Miklos Szeredi <mszeredi@suse.cz>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: Sage Weil <sage@newdream.net>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-fsdevel@vger.kernel.org
      b89f4321
    • J
      BKL: Remove BKL from CifsFS · b0991aa3
      Jan Blunck 提交于
      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: NJan Blunck <jblunck@infradead.org>
      Cc: Steve French <smfrench@gmail.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      b0991aa3
    • J
      BKL: Explicitly add BKL around get_sb/fill_super · db719222
      Jan Blunck 提交于
      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: NJan Blunck <jblunck@infradead.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Christoph Hellwig <hch@infradead.org>
      db719222
  13. 02 10月, 2010 1 次提交
    • J
      cifs: prevent infinite recursion in cifs_reconnect_tcon · f569599a
      Jeff Layton 提交于
      cifs_reconnect_tcon is called from smb_init. After a successful
      reconnect, cifs_reconnect_tcon will call reset_cifs_unix_caps. That
      function will, in turn call CIFSSMBQFSUnixInfo and CIFSSMBSetFSUnixInfo.
      Those functions also call smb_init.
      
      It's possible for the session and tcon reconnect to succeed, and then
      for another cifs_reconnect to occur before CIFSSMBQFSUnixInfo or
      CIFSSMBSetFSUnixInfo to be called. That'll cause those functions to call
      smb_init and cifs_reconnect_tcon again, ad infinitum...
      
      Break the infinite recursion by having those functions use a new
      smb_init variant that doesn't attempt to perform a reconnect.
      Reported-and-Tested-by: NMichal Suchanek <hramrach@centrum.cz>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f569599a
  14. 30 9月, 2010 2 次提交