1. 03 Oct, 2015 1 commit
  2. 20 Aug, 2015 1 commit
  3. 10 May, 2015 2 commits
    • Al Viro's avatar
      don't pass nameidata to ->follow_link() · 6e77137b
      Al Viro authored
      its only use is getting passed to nd_jump_link(), which can obtain
      it from current->nameidata
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      new ->follow_link() and ->put_link() calling conventions · 680baacb
      Al Viro authored
      a) instead of storing the symlink body (via nd_set_link()) and returning
      an opaque pointer later passed to ->put_link(), ->follow_link() _stores_
      that opaque pointer (into void * passed by address by caller) and returns
      the symlink body.  Returning ERR_PTR() on error, NULL on jump (procfs magic
      symlinks) and pointer to symlink body for normal symlinks.  Stored pointer
      is ignored in all cases except the last one.
      Storing NULL for opaque pointer (or not storing it at all) means no call
      of ->put_link().
      b) the body used to be passed to ->put_link() implicitly (via nameidata).
      Now only the opaque pointer is.  In the cases when we used the symlink body
      to free stuff, ->follow_link() now should store it as opaque pointer in addition
      to returning it.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  4. 07 Dec, 2014 1 commit
  5. 16 Sep, 2014 1 commit
  6. 07 Aug, 2014 1 commit
  7. 02 Aug, 2014 1 commit
  8. 21 May, 2014 4 commits
  9. 06 May, 2014 2 commits
  10. 24 Oct, 2013 1 commit
  11. 25 Sep, 2013 1 commit
  12. 29 Jun, 2013 1 commit
  13. 24 Jun, 2013 1 commit
  14. 13 Mar, 2013 1 commit
    • Mateusz Guzik's avatar
      cifs: delay super block destruction until all cifsFileInfo objects are gone · 24261fc2
      Mateusz Guzik authored
      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: default avatarMateusz Guzik <mguzik@redhat.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Cc: <stable@vger.kernel.org>
      Reported-and-Tested-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
  15. 24 Sep, 2012 1 commit
  16. 14 Jul, 2012 6 commits
  17. 03 May, 2012 1 commit
  18. 27 Mar, 2012 1 commit
  19. 03 Jan, 2012 3 commits
  20. 28 Oct, 2011 1 commit
  21. 12 Oct, 2011 1 commit
  22. 18 Aug, 2011 1 commit
  23. 31 Jul, 2011 1 commit
    • Jeff Layton's avatar
      cifs: simplify refcounting for oplock breaks · ad635942
      Jeff Layton authored
      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: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
  24. 20 Jul, 2011 1 commit
    • Josef Bacik's avatar
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik authored
      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.
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  25. 12 Jul, 2011 1 commit
  26. 14 Jun, 2011 1 commit
  27. 19 May, 2011 2 commits