1. 03 11月, 2013 3 次提交
    • S
      Query device characteristics at mount time from server on SMB2/3 not just on cifs mounts · 2167114c
      Steven French 提交于
      Currently SMB2 and SMB3 mounts do not query the device information at mount time
      from the server as is done for cifs.  These can be useful for debugging.
      This is a minor patch, that extends the previous one (which added ability to
      query file system attributes at mount time - this returns the device
      characteristics - also via in /proc/fs/cifs/DebugData)
      Signed-off-by: NSteve French <smfrench@gmail.com>
      2167114c
    • S
      cifs: Send a logoff request before removing a smb session · 7f48558e
      Shirish Pargaonkar 提交于
      Send a smb session logoff request before removing smb session off of the list.
      On a signed smb session, remvoing a session off of the list before sending
      a logoff request results in server returning an error for lack of
      smb signature.
      
      Never seen an error during smb logoff, so as per MS-SMB2 3.2.5.1,
      not sure how an error during logoff should be retried. So for now,
      if a server returns an error to a logoff request, log the error and
      remove the session off of the list.
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      7f48558e
    • T
      cifs: Make big endian multiplex ID sequences monotonic on the wire · 3d378d3f
      Tim Gardner 提交于
      The multiplex identifier (MID) in the SMB header is only
      ever used by the client, in conjunction with PID, to match responses
      from the server. As such, the endianess of the MID is not important.
      However, When tracing packet sequences on the wire, protocol analyzers
      such as wireshark display MID as little endian. It is much more informative
      for the on-the-wire MID sequences to match debug information emitted by the
      CIFS driver.  Therefore, one should write and read MID in the SMB header
      assuming it is always little endian.
      
      Observed from wireshark during the protocol negotiation
      and session setup:
      
              Multiplex ID: 256
              Multiplex ID: 256
              Multiplex ID: 512
              Multiplex ID: 512
              Multiplex ID: 768
              Multiplex ID: 768
      
      After this patch on-the-wire MID values begin at 1 and increase monotonically.
      
      Introduce get_next_mid64() for the internal consumers that use the full 64 bit
      multiplex identifier.
      
      Introduce the helpers get_mid() and compare_mid() to make the endian
      translation clear.
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTim Gardner <timg@tpi.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      3d378d3f
  2. 28 10月, 2013 4 次提交
  3. 15 10月, 2013 1 次提交
  4. 07 10月, 2013 3 次提交
  5. 06 10月, 2013 1 次提交
    • S
      do not treat non-symlink reparse points as valid symlinks · c31f3307
      Steve French 提交于
      Windows 8 and later can create NFS symlinks (within reparse points)
      which we were assuming were normal NTFS symlinks and thus reporting
      corrupt paths for.  Add check for reparse points to make sure that
      they really are normal symlinks before we try to parse the pathname.
      
      We also should not be parsing other types of reparse points (DFS
      junctions etc) as if they were a  symlink so return EOPNOTSUPP
      on those.  Also fix endian errors (we were not parsing symlink
      lengths as little endian).
      
      This fixes commit d244bf2d
      which implemented follow link for non-Unix CIFS mounts
      
      CC: Stable <stable@kernel.org>
      Reviewed-by: NAndrew Bartlett <abartlet@samba.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      c31f3307
  6. 26 9月, 2013 2 次提交
  7. 21 9月, 2013 1 次提交
  8. 18 9月, 2013 2 次提交
    • J
      cifs: stop trying to use virtual circuits · 9ae6cf60
      Jeff Layton 提交于
      Currently, we try to ensure that we use vcnum of 0 on the first
      established session on a connection and then try to use a different
      vcnum on each session after that.
      
      This is a little odd, since there's no real reason to use a different
      vcnum for each SMB session. I can only assume there was some confusion
      between SMB sessions and VCs. That's somewhat understandable since they
      both get created during SESSION_SETUP, but the documentation indicates
      that they are really orthogonal. The comment on max_vcs in particular
      looks quite misguided. An SMB session is already uniquely identified
      by the SMB UID value -- there's no need to again uniquely ID with a
      VC.
      
      Furthermore, a vcnum of 0 is a cue to the server that it should release
      any resources that were previously held by the client. This sounds like
      a good thing, until you consider that:
      
      a) it totally ignores the fact that other programs on the box (e.g.
      smbclient) might have connections established to the server. Using a
      vcnum of 0 causes them to get kicked off.
      
      b) it causes problems with NAT. If several clients are connected to the
      same server via the same NAT'ed address, whenever one connects to the
      server it kicks off all the others, which then reconnect and kick off
      the first one...ad nauseum.
      
      I don't see any reason to ignore the advice in "Implementing CIFS" which
      has a comprehensive treatment of virtual circuits. In there, it states
      "...and contrary to the specs the client should always use a VcNumber of
      one, never zero."
      
      Have the client just use a hardcoded vcnum of 1, and stop abusing the
      special behavior of vcnum 0.
      Reported-by: NSauron99@gmx.de <sauron99@gmx.de>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NVolker Lendecke <vl@samba.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      9ae6cf60
    • D
      CIFS: FS-Cache: Uncache unread pages in cifs_readpages() before freeing them · 54afa990
      David Howells 提交于
      In cifs_readpages(), we may decide we don't want to read a page after all -
      but the page may already have passed through fscache_read_or_alloc_pages() and
      thus have marks and reservations set.  Thus we have to call
      fscache_readpages_cancel() or fscache_uncache_page() on the pages we're
      returning to clear the marks.
      
      NFS, AFS and 9P should be unaffected by this as they call read_cache_pages()
      which does the cleanup for you.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      54afa990
  9. 17 9月, 2013 1 次提交
  10. 14 9月, 2013 2 次提交
  11. 13 9月, 2013 1 次提交
  12. 10 9月, 2013 5 次提交
  13. 09 9月, 2013 14 次提交