1. 07 5月, 2014 1 次提交
  2. 25 10月, 2013 1 次提交
  3. 26 9月, 2013 1 次提交
  4. 29 6月, 2013 1 次提交
  5. 24 6月, 2013 1 次提交
  6. 14 3月, 2013 1 次提交
    • M
      cifs: delay super block destruction until all cifsFileInfo objects are gone · 24261fc2
      Mateusz Guzik 提交于
      cifsFileInfo objects hold references to dentries and it is possible that
      these will still be around in workqueues when VFS decides to kill super
      block during unmount.
      
      This results in panics like this one:
      BUG: Dentry ffff88001f5e76c0{i=66b4a,n=1M-2} still in use (1) [unmount of cifs cifs]
      ------------[ cut here ]------------
      kernel BUG at fs/dcache.c:943!
      [..]
      Process umount (pid: 1781, threadinfo ffff88003d6e8000, task ffff880035eeaec0)
      [..]
      Call Trace:
       [<ffffffff811b44f3>] shrink_dcache_for_umount+0x33/0x60
       [<ffffffff8119f7fc>] generic_shutdown_super+0x2c/0xe0
       [<ffffffff8119f946>] kill_anon_super+0x16/0x30
       [<ffffffffa036623a>] cifs_kill_sb+0x1a/0x30 [cifs]
       [<ffffffff8119fcc7>] deactivate_locked_super+0x57/0x80
       [<ffffffff811a085e>] deactivate_super+0x4e/0x70
       [<ffffffff811bb417>] mntput_no_expire+0xd7/0x130
       [<ffffffff811bc30c>] sys_umount+0x9c/0x3c0
       [<ffffffff81657c19>] system_call_fastpath+0x16/0x1b
      
      Fix this by making each cifsFileInfo object hold a reference to cifs
      super block, which implicitly keeps VFS super block around as well.
      Signed-off-by: NMateusz Guzik <mguzik@redhat.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Cc: <stable@vger.kernel.org>
      Reported-and-Tested-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      24261fc2
  7. 25 9月, 2012 1 次提交
  8. 14 7月, 2012 6 次提交
  9. 04 5月, 2012 1 次提交
  10. 28 3月, 2012 1 次提交
  11. 04 1月, 2012 3 次提交
  12. 29 10月, 2011 1 次提交
  13. 13 10月, 2011 1 次提交
  14. 19 8月, 2011 1 次提交
  15. 01 8月, 2011 1 次提交
    • J
      cifs: simplify refcounting for oplock breaks · ad635942
      Jeff Layton 提交于
      Currently, we take a sb->s_active reference and a cifsFileInfo reference
      when an oplock break workqueue job is queued. This is unnecessary and
      more complicated than it needs to be. Also as Al points out,
      deactivate_super has non-trivial locking implications so it's best to
      avoid that if we can.
      
      Instead, just cancel any pending oplock breaks for this filehandle
      synchronously in cifsFileInfo_put after taking it off the lists.
      That should ensure that this job doesn't outlive the structures it
      depends on.
      Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ad635942
  16. 21 7月, 2011 1 次提交
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik 提交于
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
      in fsync to make it less of a painful operation, so push down taking i_mutex and
      the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
      file systems can drop taking the i_mutex altogether it seems, like ext3 and
      ocfs2.  For correctness sake I just pushed everything down in all cases to make
      sure that we keep the current behavior the same for everybody, and then each
      individual fs maintainer can make up their mind about what to do from there.
      Thanks,
      Acked-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  17. 13 7月, 2011 1 次提交
  18. 15 6月, 2011 1 次提交
  19. 19 5月, 2011 5 次提交
  20. 22 2月, 2011 1 次提交
  21. 01 2月, 2011 1 次提交
  22. 26 1月, 2011 1 次提交
  23. 21 1月, 2011 3 次提交
  24. 20 1月, 2011 1 次提交
  25. 16 1月, 2011 1 次提交
  26. 25 10月, 2010 1 次提交
  27. 18 10月, 2010 1 次提交