1. 17 10月, 2014 1 次提交
    • S
      Allow mknod and mkfifo on SMB2/SMB3 mounts · db8b631d
      Steve French 提交于
      The "sfu" mount option did not work on SMB2/SMB3 mounts.
      With these changes when the "sfu" mount option is passed in
      on an smb2/smb2.1/smb3 mount the client can emulate (and
      recognize) fifo and device (character and device files).
      
      In addition the "sfu" mount option should not conflict
      with "mfsymlinks" (symlink emulation) as we will never
      create "sfu" style symlinks, but using "sfu" mount option
      will allow us to recognize existing symlinks, created with
      Microsoft "Services for Unix" (SFU and SUA).
      
      To enable the "sfu" mount option for SMB2/SMB3 the calling
      syntax of the generic cifs/smb2/smb3 sync_read and sync_write
      protocol dependent function needed to be changed (we
      don't have a file struct in all cases), but this actually
      ended up simplifying the code a little.
      Signed-off-by: NSteve French <smfrench@gmail.com>
      db8b631d
  2. 26 8月, 2014 1 次提交
  3. 18 8月, 2014 1 次提交
  4. 17 8月, 2014 1 次提交
    • P
      CIFS: Fix SMB2 readdir error handling · 52755808
      Pavel Shilovsky 提交于
      SMB2 servers indicates the end of a directory search with
      STATUS_NO_MORE_FILE error code that is not processed now.
      This causes generic/257 xfstest to fail. Fix this by triggering
      the end of search by this error code in SMB2_query_directory.
      
      Also when negotiating CIFS protocol we tell the server to close
      the search automatically at the end and there is no need to do
      it itself. In the case of SMB2 protocol, we need to close it
      explicitly - separate close directory checks for different
      protocols.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      52755808
  5. 14 8月, 2014 1 次提交
    • S
      Add sparse file support to SMB2/SMB3 mounts · 3d1a3745
      Steve French 提交于
      Many Linux filesystes make a file "sparse" when extending
      a file with ftruncate. This does work for CIFS to Samba
      (only) but not for SMB2/SMB3 (to Samba or Windows) since
      there is a "set sparse" fsctl which is supposed to be
      sent to mark a file as sparse.
      
      This patch marks a file as sparse by sending this simple
      set sparse fsctl if it is extended more than 2 pages.
      It has been tested to Windows 8.1, Samba and various
      SMB2/SMB3 servers which do support setting sparse (and
      MacOS which does not appear to support the fsctl yet).
      If a server share does not support setting a file
      as sparse, then we do not retry setting sparse on that
      share.
      
      The disk space savings for sparse files can be quite
      large (even more significant on Windows servers than Samba).
      Signed-off-by: NSteve French <smfrench@gmail.com>
      Reviewed-by: NShirish Pargaonkar <spargaonkar@suse.com>
      3d1a3745
  6. 02 8月, 2014 4 次提交
  7. 22 5月, 2014 3 次提交
    • S
      cifs: Set client guid on per connection basis · 39552ea8
      Sachin Prabhu 提交于
      When mounting from a Windows 2012R2 server, we hit the following
      problem:
      1) Mount with any of the following versions - 2.0, 2.1 or 3.0
      2) unmount
      3) Attempt a mount again using a different SMB version >= 2.0.
      
      You end up with the following failure:
      Status code returned 0xc0000203 STATUS_USER_SESSION_DELETED
      CIFS VFS: Send error in SessSetup = -5
      CIFS VFS: cifs_mount failed w/return code = -5
      
      I cannot reproduce this issue using a Windows 2008 R2 server.
      
      This appears to be caused because we use the same client guid for the
      connection on first mount which we then disconnect and attempt to mount
      again using a different protocol version. By generating a new guid each
      time a new connection is Negotiated, we avoid hitting this problem.
      Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      39552ea8
    • J
      cifs: fix potential races in cifs_revalidate_mapping · 4f73c7d3
      Jeff Layton 提交于
      The handling of the CIFS_INO_INVALID_MAPPING flag is racy. It's possible
      for two tasks to attempt to revalidate the mapping at the same time. The
      first sees that CIFS_INO_INVALID_MAPPING is set. It clears the flag and
      then calls invalidate_inode_pages2 to start shooting down the pagecache.
      
      While that's going on, another task checks the flag and sees that it's
      clear. It then ends up trusting the pagecache to satisfy a read when it
      shouldn't.
      
      Fix this by adding a bitlock to ensure that the clearing of the flag is
      atomic with respect to the actual cache invalidation. Also, move the
      other existing users of cifs_invalidate_mapping to use a new
      cifs_zap_mapping() function that just sets the INVALID_MAPPING bit and
      then uses the standard codepath to handle the invalidation.
      Signed-off-by: NJeff Layton <jlayton@poochiereds.net>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      4f73c7d3
    • J
      cifs: convert booleans in cifsInodeInfo to a flags field · aff8d5ca
      Jeff Layton 提交于
      In later patches, we'll need to have a bitlock, so go ahead and convert
      these bools to use atomic bitops instead.
      
      Also, clean up the initialization of the flags field. There's no need
      to unset each bit individually just after it was zeroed on allocation.
      Signed-off-by: NJeff Layton <jlayton@poochiereds.net>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      aff8d5ca
  8. 17 4月, 2014 1 次提交
    • S
      cifs: Wait for writebacks to complete before attempting write. · c11f1df5
      Sachin Prabhu 提交于
      Problem reported in Red Hat bz 1040329 for strict writes where we cache
      only when we hold oplock and write direct to the server when we don't.
      
      When we receive an oplock break, we first change the oplock value for
      the inode in cifsInodeInfo->oplock to indicate that we no longer hold
      the oplock before we enqueue a task to flush changes to the backing
      device. Once we have completed flushing the changes, we return the
      oplock to the server.
      
      There are 2 ways here where we can have data corruption
      1) While we flush changes to the backing device as part of the oplock
      break, we can have processes write to the file. These writes check for
      the oplock, find none and attempt to write directly to the server.
      These direct writes made while we are flushing from cache could be
      overwritten by data being flushed from the cache causing data
      corruption.
      2) While a thread runs in cifs_strict_writev, the machine could receive
      and process an oplock break after the thread has checked the oplock and
      found that it allows us to cache and before we have made changes to the
      cache. In that case, we end up with a dirty page in cache when we
      shouldn't have any. This will be flushed later and will overwrite all
      subsequent writes to the part of the file represented by this page.
      
      Before making any writes to the server, we need to confirm that we are
      not in the process of flushing data to the server and if we are, we
      should wait until the process is complete before we attempt the write.
      We should also wait for existing writes to complete before we process
      an oplock break request which changes oplock values.
      
      We add a version specific  downgrade_oplock() operation to allow for
      differences in the oplock values set for the different smb versions.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      c11f1df5
  9. 01 3月, 2014 1 次提交
  10. 11 2月, 2014 1 次提交
    • S
      [CIFS] Fix cifsacl mounts over smb2 to not call cifs · 42eacf9e
      Steve French 提交于
      When mounting with smb2/smb3 (e.g. vers=2.1) and cifsacl mount option,
      it was trying to get the mode by querying the acl over the cifs
      rather than smb2 protocol.  This patch makes that protocol
      independent and makes cifsacl smb2 mounts return a more intuitive
      operation not supported error (until we add a worker function
      for smb2_get_acl).
      
      Note that a previous patch fixed getxattr/setxattr for the CIFSACL xattr
      which would unconditionally call cifs_get_acl and cifs_set_acl (even when
      mounted smb2). I made those protocol independent last week (new protocol
      version operations "get_acl" and "set_acl" but did not add an
      smb2_get_acl and smb2_set_acl yet so those now simply return EOPNOTSUPP
      which at least is better than sending cifs requests on smb2 mount)
      
      The previous patches did not fix the one remaining case though ie
      mounting with "cifsacl" when getting mode from acl would unconditionally
      end up calling "cifs_get_acl_from_fid" even for smb2 - so made that protocol
      independent but to make that protocol independent had to make sure that the callers
      were passing the protocol independent handle structure (cifs_fid) instead
      of cifs specific _u16 network file handle (ie cifs_fid instead of cifs_fid->fid)
      
      Now mount with smb2 and cifsacl mount options will return EOPNOTSUP (instead
      of timing out) and a future patch will add smb2 operations (e.g. get_smb2_acl)
      to enable this.
      Signed-off-by: NSteve French <smfrench@gmail.com>
      42eacf9e
  11. 08 2月, 2014 3 次提交
  12. 27 1月, 2014 1 次提交
  13. 20 1月, 2014 2 次提交
  14. 20 11月, 2013 1 次提交
  15. 16 11月, 2013 1 次提交
  16. 14 11月, 2013 1 次提交
    • S
      CIFS: SMB2/SMB3 Copy offload support (refcopy) phase 1 · 41c1358e
      Steve French 提交于
      This first patch adds the ability for us to do a server side copy
      (ie fast copy offloaded to the server to perform, aka refcopy)
      
      "cp --reflink"
      
      of one file to another located on the same server.  This
      is much faster than traditional copy (which requires
      reading and writing over the network and extra
      memcpys).
      
      This first version is not going to be copy
      files larger than about 1MB (to Samba) until I add
      support for multiple chunks and for autoconfiguring
      the chunksize.
      
      It includes:
      1) processing of the ioctl
      2) marshalling and sending the SMB2/SMB3 fsctl over the network
      3) simple parsing of the response
      
      It does not include yet (these will be in followon patches to come soon):
      1) support for multiple chunks
      2) support for autoconfiguring and remembering the chunksize
      3) Support for the older style copychunk which Samba 4.1 server supports
      (because this requires write permission on the target file, which
      cp does not give you, apparently per-posix).  This may require
      a distinct tool (other than cp) and other ioctl to implement.
      Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      41c1358e
  17. 12 11月, 2013 1 次提交
  18. 03 11月, 2013 2 次提交
    • S
      Query File System Alignment · af6a12ea
      Steven French 提交于
      In SMB3 it is now possible to query the file system
      alignment info, and the preferred (for performance)
      sector size and whether the underlying disk
      has no seek penalty (like SSD).
      
      Query this information at mount time for SMB3,
      and make it visible in /proc/fs/cifs/DebugData
      for debugging purposes.
      
      This alignment information and preferred sector
      size info will be helpful for the copy offload
      patches to setup the right chunks in the CopyChunk
      requests.   Presumably the knowledge that the
      underlying disk is SSD could also help us
      make better readahead and writebehind
      decisions (something to look at in the future).
      Signed-off-by: NSteve French <smfrench@gmail.com>
      af6a12ea
    • 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
  19. 28 10月, 2013 1 次提交
    • S
      Allow setting per-file compression via SMB2/3 · 64a5cfa6
      Steve French 提交于
      Allow cifs/smb2/smb3 to return whether or not a file is compressed
      via lsattr, and allow SMB2/SMB3 to set the per-file compression
      flag ("chattr +c filename" on an smb3 mount).
      
      Windows users often set the compressed flag (it can be
      done from the desktop and file manager).  David Disseldorp
      has patches to Samba server to support this (at least on btrfs)
      which are complementary to this
      Signed-off-by: NSteve French <smfrench@gmail.com>
      64a5cfa6
  20. 21 9月, 2013 1 次提交
  21. 18 9月, 2013 1 次提交
    • 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
  22. 10 9月, 2013 4 次提交
  23. 09 9月, 2013 6 次提交