1. 04 8月, 2009 1 次提交
  2. 02 8月, 2009 1 次提交
  3. 30 7月, 2009 1 次提交
  4. 28 7月, 2009 1 次提交
  5. 23 7月, 2009 3 次提交
    • S
      [CIFS] fix sparse warning · f1230c97
      Steve French 提交于
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f1230c97
    • J
      cifs: fix sb->s_maxbytes so that it casts properly to a signed value · 03aa3a49
      Jeff Layton 提交于
      This off-by-one bug causes sendfile() to not work properly. When a task
      calls sendfile() on a file on a CIFS filesystem, the syscall returns -1
      and sets errno to EOVERFLOW.
      
      do_sendfile uses s_maxbytes to verify the returned offset of the file.
      The problem there is that this value is cast to a signed value (loff_t).
      When this is done on the s_maxbytes value that cifs uses, it becomes
      negative and the comparisons against it fail.
      
      Even though s_maxbytes is an unsigned value, it seems that it's not OK
      to set it in such a way that it'll end up negative when it's cast to a
      signed value. These casts happen in other codepaths besides sendfile
      too, but the VFS is a little hard to follow in this area and I can't
      be sure if there are other bugs that this will fix.
      
      It's not clear to me why s_maxbytes isn't just declared as loff_t in the
      first place, but either way we still need to fix these values to make
      sendfile work properly. This is also an opportunity to replace the magic
      bit-shift values here with the standard #defines for this.
      
      This fixes the reproducer program I have that does a sendfile and
      will probably also fix the situation where apache is serving from a
      CIFS share.
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      03aa3a49
    • J
      cifs: disable serverino if server doesn't support it · ce6e7fcd
      Jeff Layton 提交于
      A recent regression when dealing with older servers. This bug was
      introduced when we made serverino the default...
      
      When the server can't provide inode numbers, disable it for the mount.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ce6e7fcd
  6. 21 7月, 2009 1 次提交
  7. 10 7月, 2009 9 次提交
  8. 09 7月, 2009 1 次提交
  9. 02 7月, 2009 1 次提交
    • J
      cifs: add new cifs_iget function and convert unix codepath to use it · cc0bad75
      Jeff Layton 提交于
      cifs: add new cifs_iget function and convert unix codepath to use it
      
      In order to unify some codepaths, introduce a common cifs_fattr struct
      for storing inode attributes. The different codepaths (unix, legacy,
      normal, etc...) can fill out this struct with inode info. It can then be
      passed as an arg to a common set of routines to get and update inodes.
      
      Add a new cifs_iget function that uses iget5_locked to identify inodes.
      This will compare inodes based on the uniqueid value in a cifs_fattr
      struct.
      
      Rather than filling out an already-created inode, have
      cifs_get_inode_info_unix instead fill out cifs_fattr and hand that off
      to cifs_iget. cifs_iget can then properly look for hardlinked inodes.
      
      On the readdir side, add a new cifs_readdir_lookup function that spawns
      populated dentries. Redefine FILE_UNIX_INFO so that it's basically a
      FILE_UNIX_BASIC_INFO that has a few fields wrapped around it. This
      allows us to more easily use the same function for filling out the fattr
      as the non-readdir codepath.
      
      With this, we should then have proper hardlink detection and can
      eventually get rid of some nasty CIFS-specific hacks for handing them.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      cc0bad75
  10. 28 6月, 2009 1 次提交
  11. 26 6月, 2009 3 次提交
    • S
      [CIFS] remove unknown mount option warning message · 71a394fa
      Steve French 提交于
      Jeff's previous patch which removed the unneeded rw/ro
      parsing can cause a minor warning in dmesg (about the
      unknown rw or ro mount option) at mount time. This
      patch makes cifs ignore them in kernel to remove the warning
      (they are already handled in the mount helper and VFS).
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      71a394fa
    • S
      [CIFS] remove bkl usage from umount begin · ad8034f1
      Steve French 提交于
      The lock_kernel call moved into the fs for umount_begin
      is not needed.  This adds a check to make sure we don't
      call umount_begin twice on the same fs.
      
      umount_begin for cifs is probably not needed and
      may eventually be able to be removed, but in
      the meantime this smaller patch is safe and
      gets rid of the bkl from this path which provides
      some benefit.
      
      Acked-by: Jeff Layton <redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ad8034f1
    • S
      cifs: Fix incorrect return code being printed in cFYI messages · 0f3bc09e
      Suresh Jayaraman 提交于
      FreeXid() along with freeing Xid does add a cifsFYI debug message that
      prints rc (return code) as well. In some code paths where we set/return
      error code after calling FreeXid(), incorrect error code is being
      printed when cifsFYI is enabled.
      
      This could be misleading in few cases. For eg.
      In cifs_open() if cifs_fill_filedata() returns a valid pointer to
      cifsFileInfo, FreeXid() prints rc=-13 whereas 0 is actually being
      returned. Fix this by setting rc before calling FreeXid().
      
      Basically convert
      
      FreeXid(xid);			rc = -ERR;
      return -ERR;		=>	FreeXid(xid);
      				return rc;
      
      [Note that Christoph would like to replace the GetXid/FreeXid
      calls, which are primarily used for debugging.  This seems
      like a good longer term goal, but although there is an
      alternative tracing facility, there are no examples yet
      available that I know of that we can use (yet) to
      convert this cifs function entry/exit logging, and for
      creating an identifier that we can use to correlate
      all dmesg log entries for a particular vfs operation
      (ie identify all log entries for a particular vfs
      request to cifs: e.g. a particular close or read or write
      or byte range lock call ... and just using the thread id
      is harder).  Eventually when a replacement
      for this is available (e.g. when NFS switches over and various
      samples to look at in other file systems) we can remove the
      GetXid/FreeXid macro but in the meantime multiple people
      use this run time configurable logging all the time
      for debugging, and Suresh's patch fixes a problem
      which made it harder to notice some low
      memory problems in the log so it is worthwhile
      to fix this problem until a better logging
      approach is able to be used]
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSuresh Jayaraman <sjayaraman@suse.de>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      0f3bc09e
  12. 25 6月, 2009 6 次提交
  13. 15 6月, 2009 2 次提交
  14. 13 6月, 2009 3 次提交
  15. 12 6月, 2009 2 次提交
    • C
      push BKL down into ->put_super · 6cfd0148
      Christoph Hellwig 提交于
      Move BKL into ->put_super from the only caller.  A couple of
      filesystems had trivial enough ->put_super (only kfree and NULLing of
      s_fs_info + stuff in there) to not get any locking: coda, cramfs, efs,
      hugetlbfs, omfs, qnx4, shmem, all others got the full treatment.  Most
      of them probably don't need it, but I'd rather sort that out individually.
      Preferably after all the other BKL pushdowns in that area.
      
      [AV: original used to move lock_super() down as well; these changes are
      removed since we don't do lock_super() at all in generic_shutdown_super()
      now]
      [AV: fuse, btrfs and xfs are known to need no damn BKL, exempt]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6cfd0148
    • A
      switch follow_down() · 9393bd07
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9393bd07
  16. 11 6月, 2009 1 次提交
  17. 10 6月, 2009 1 次提交
  18. 07 6月, 2009 2 次提交
    • S
      [CIFS] Add mention of new mount parm (forceuid) to cifs readme · f0472d0e
      Steve French 提交于
      Also update fs/cifs/CHANGES
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f0472d0e
    • J
      cifs: make overriding of ownership conditional on new mount options · 4ae1507f
      Jeff Layton 提交于
      We have a bit of a problem with the uid= option. The basic issue is that
      it means too many things and has too many side-effects.
      
      It's possible to allow an unprivileged user to mount a filesystem if the
      user owns the mountpoint, /bin/mount is setuid root, and the mount is
      set up in /etc/fstab with the "user" option.
      
      When doing this though, /bin/mount automatically adds the "uid=" and
      "gid=" options to the share. This is fortunate since the correct uid=
      option is needed in order to tell the upcall what user's credcache to
      use when generating the SPNEGO blob.
      
      On a mount without unix extensions this is fine -- you generally will
      want the files to be owned by the "owner" of the mount. The problem
      comes in on a mount with unix extensions. With those enabled, the
      uid/gid options cause the ownership of files to be overriden even though
      the server is sending along the ownership info.
      
      This means that it's not possible to have a mount by an unprivileged
      user that shows the server's file ownership info. The result is also
      inode permissions that have no reflection at all on the server. You
      simply cannot separate ownership from the mode in this fashion.
      
      This behavior also makes MultiuserMount option less usable. Once you
      pass in the uid= option for a mount, then you can't use unix ownership
      info and allow someone to share the mount.
      
      While I'm not thrilled with it, the only solution I can see is to stop
      making uid=/gid= force the overriding of ownership on mounts, and to add
      new mount options that turn this behavior on.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      4ae1507f