1. 25 9月, 2009 1 次提交
    • J
      cifs: convert oplock breaks to use slow_work facility (try #4) · 3bc303c2
      Jeff Layton 提交于
      This is the fourth respin of the patch to convert oplock breaks to
      use the slow_work facility.
      
      A customer of ours was testing a backport of one of the earlier
      patchsets, and hit a "Busy inodes after umount..." problem. An oplock
      break job had raced with a umount, and the superblock got torn down and
      its memory reused. When the oplock break job tried to dereference the
      inode->i_sb, the kernel oopsed.
      
      This patchset has the oplock break job hold an inode and vfsmount
      reference until the oplock break completes.  With this, there should be
      no need to take a tcon reference (the vfsmount implicitly holds one
      already).
      
      Currently, when an oplock break comes in there's a chance that the
      oplock break job won't occur if the allocation of the oplock_q_entry
      fails. There are also some rather nasty races in the allocation and
      handling these structs.
      
      Rather than allocating oplock queue entries when an oplock break comes
      in, add a few extra fields to the cifsFileInfo struct. Get rid of the
      dedicated cifs_oplock_thread as well and queue the oplock break job to
      the slow_work thread pool.
      
      This approach also has the advantage that the oplock break jobs can
      potentially run in parallel rather than be serialized like they are
      today.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      3bc303c2
  2. 16 9月, 2009 2 次提交
  3. 30 4月, 2009 2 次提交
  4. 26 12月, 2008 2 次提交
  5. 21 11月, 2008 1 次提交
    • S
      [CIFS] Do not attempt to close invalidated file handles · ddb4cbfc
      Steve French 提交于
      If a connection with open file handles has gone down
      and come back up and reconnected without reopening
      the file handle yet, do not attempt to send an SMB close
      request for this handle in cifs_close.  We were
      checking for the connection being invalid in cifs_close
      but since the connection may have been reconnected
      we also need to check whether the file handle
      was marked invalid (otherwise we could close the
      wrong file handle by accident).
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ddb4cbfc
  6. 17 11月, 2008 1 次提交
  7. 15 11月, 2008 1 次提交
    • J
      cifs: reinstate sharing of SMB sessions sans races · 14fbf50d
      Jeff Layton 提交于
      We do this by abandoning the global list of SMB sessions and instead
      moving to a per-server list. This entails adding a new list head to the
      TCP_Server_Info struct. The refcounting for the cifsSesInfo is moved to
      a non-atomic variable. We have to protect it by a lock anyway, so there's
      no benefit to making it an atomic. The list and refcount are protected
      by the global cifs_tcp_ses_lock.
      
      The patch also adds a new routines to find and put SMB sessions and
      that properly take and put references under the lock.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      14fbf50d
  8. 14 11月, 2008 1 次提交
  9. 12 10月, 2008 1 次提交
  10. 23 9月, 2008 1 次提交
  11. 24 5月, 2008 1 次提交
  12. 29 4月, 2008 1 次提交
  13. 08 2月, 2008 1 次提交
  14. 26 10月, 2007 1 次提交
  15. 29 9月, 2007 1 次提交
  16. 18 7月, 2007 1 次提交
  17. 13 7月, 2007 1 次提交
  18. 10 7月, 2007 1 次提交
  19. 08 7月, 2007 1 次提交
  20. 22 1月, 2007 1 次提交
  21. 08 12月, 2006 2 次提交
  22. 13 10月, 2006 1 次提交
  23. 29 9月, 2006 1 次提交
  24. 01 6月, 2006 1 次提交
  25. 05 3月, 2006 1 次提交
    • S
      [CIFS] Always match oplock break (cache notification) to the right tcp · e77e6f3b
      Steve French 提交于
      session when multiply mounted.
      
      Fixes slow response when cifs client is mounted to shares on multiple
      servers and oplock break occurs (usually due to attempt to multiply open a
      file).  When treeids on mutiple mounted shares match and we find the wrong
      match first, we searched for the wrong cached files to send oplock break
      response for which usually meant that no matching file was found and thus
      the server would have to timeout the notification.  Oplock break timeout is
      about 20 seconds on some servers so this could cause significantly slower
      performance on file open calls in a few cases (in particular when multiple
      shares are mounted from multiple servers, tree ids match, and we have a
      cached file which is later opened multiple times).  This was the most
      important of the bugs that was found and fixed at Connectathon
      (interoperability testing event) this week.
      
      Acked-by:  Shaggy (shaggy@austin.ibm.com)
      Signed-off-by: Steve French (sfrench@us.ibm.com)
      e77e6f3b
  26. 03 3月, 2006 1 次提交
  27. 02 3月, 2006 1 次提交
  28. 24 2月, 2006 1 次提交
  29. 22 2月, 2006 1 次提交
  30. 13 12月, 2005 1 次提交
  31. 04 12月, 2005 1 次提交
  32. 02 12月, 2005 1 次提交
  33. 30 11月, 2005 1 次提交
  34. 12 11月, 2005 1 次提交
  35. 07 11月, 2005 1 次提交
  36. 11 10月, 2005 1 次提交