1. 17 6月, 2010 3 次提交
    • J
      cifs: clean up arguments to cifs_open_inode_helper · db460242
      Jeff Layton 提交于
      ...which takes a ton of unneeded arguments and does a lot more pointer
      dereferencing than is really needed.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-and-Tested-by: NSuresh Jayaraman <sjayaraman@suse.de>
      db460242
    • J
      cifs: pass instantiated filp back after open call · 6ca9f3ba
      Jeff Layton 提交于
      The current scheme of sticking open files on a list and assuming that
      cifs_open will scoop them off of it is broken and leads to "Busy
      inodes after umount..." errors at unmount time.
      
      The problem is that there is no guarantee that cifs_open will always
      be called after a ->lookup or ->create operation. If there are
      permissions or other problems, then it's quite likely that it *won't*
      be called.
      
      Fix this by fully instantiating the filp whenever the file is created
      and pass that filp back to the VFS. If there is a problem, the VFS
      can clean up the references.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-and-Tested-by: NSuresh Jayaraman <sjayaraman@suse.de>
      6ca9f3ba
    • J
      cifs: move cifs_new_fileinfo call out of cifs_posix_open · 2422f676
      Jeff Layton 提交于
      Having cifs_posix_open call cifs_new_fileinfo is problematic and
      inconsistent with how "regular" opens work. It's also buggy as
      cifs_reopen_file calls this function on a reconnect, which creates a new
      struct cifsFileInfo that just gets leaked.
      
      Push it out into the callers. This also allows us to get rid of the
      "mnt" arg to cifs_posix_open.
      
      Finally, in the event that a cifsFileInfo isn't or can't be created, we
      always want to close the filehandle out on the server as the client
      won't have a record of the filehandle and can't actually use it. Make
      sure that CIFSSMBClose is called in those cases.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-and-Tested-by: NSuresh Jayaraman <sjayaraman@suse.de>
      2422f676
  2. 16 6月, 2010 1 次提交
  3. 12 6月, 2010 29 次提交
  4. 11 6月, 2010 7 次提交