1. 11 12月, 2014 1 次提交
  2. 16 9月, 2014 1 次提交
    • A
      cifs: remove dead code · 116ae5e2
      Arnd Bergmann 提交于
      cifs provides two dummy functions 'sess_auth_lanman' and
      'sess_auth_kerberos' for the case in which the respective
      features are not defined. However, the caller is also under
      an #ifdef, so we just get warnings about unused code:
      
      fs/cifs/sess.c:1109:1: warning: 'sess_auth_kerberos' defined but not used [-Wunused-function]
       sess_auth_kerberos(struct sess_data *sess_data)
      
      Removing the dead functions gets rid of the warnings without
      any downsides that I can see.
      
      (Yalin Wang reported the identical problem and fix so added him)
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NYalin Wang <yalin.wang@sonymobile.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      116ae5e2
  3. 22 8月, 2014 1 次提交
  4. 02 8月, 2014 1 次提交
  5. 01 8月, 2014 4 次提交
  6. 07 10月, 2013 1 次提交
  7. 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
  8. 09 9月, 2013 3 次提交
  9. 31 7月, 2013 1 次提交
  10. 24 6月, 2013 5 次提交
  11. 05 5月, 2013 2 次提交
    • J
      [CIFS] cifs: Rename cERROR and cFYI to cifs_dbg · f96637be
      Joe Perches 提交于
      It's not obvious from reading the macro names that these macros
      are for debugging.  Convert the names to a single more typical
      kernel style cifs_dbg macro.
      
      	cERROR(1, ...)   -> cifs_dbg(VFS, ...)
      	cFYI(1, ...)     -> cifs_dbg(FYI, ...)
      	cFYI(DBG2, ...)  -> cifs_dbg(NOISY, ...)
      
      Move the terminating format newline from the macro to the call site.
      
      Add CONFIG_CIFS_DEBUG function cifs_vfs_err to emit the
      "CIFS VFS: " prefix for VFS messages.
      
      Size is reduced ~ 1% when CONFIG_CIFS_DEBUG is set (default y)
      
      $ size fs/cifs/cifs.ko*
         text    data     bss     dec     hex filename
       265245	   2525	    132	 267902	  4167e	fs/cifs/cifs.ko.new
       268359    2525     132  271016   422a8 fs/cifs/cifs.ko.old
      
      Other miscellaneous changes around these conversions:
      
      o Miscellaneous typo fixes
      o Add terminating \n's to almost all formats and remove them
        from the macros to be more kernel style like.  A few formats
        previously had defective \n's
      o Remove unnecessary OOM messages as kmalloc() calls dump_stack
      o Coalesce formats to make grep easier,
        added missing spaces when coalescing formats
      o Use %s, __func__ instead of embedded function name
      o Removed unnecessary "cifs: " prefixes
      o Convert kzalloc with multiply to kcalloc
      o Remove unused cifswarn macro
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      f96637be
    • S
      fs: cifs: use kmemdup instead of kmalloc + memcpy · f7f7c185
      Silviu-Mihai Popescu 提交于
      This replaces calls to kmalloc followed by memcpy with a single call to
      kmemdup. This was found via make coccicheck.
      Signed-off-by: NSilviu-Mihai Popescu <silviupopescu1990@gmail.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      f7f7c185
  12. 27 9月, 2012 1 次提交
  13. 25 7月, 2012 1 次提交
  14. 24 7月, 2012 3 次提交
  15. 03 2月, 2012 1 次提交
  16. 31 1月, 2012 1 次提交
  17. 19 1月, 2012 1 次提交
  18. 30 10月, 2011 1 次提交
  19. 13 10月, 2011 1 次提交
    • J
      cifs: untangle server->maxBuf and CIFSMaxBufSize · c974befa
      Jeff Layton 提交于
      server->maxBuf is the maximum SMB size (including header) that the
      server can handle. CIFSMaxBufSize is the maximum amount of data (sans
      header) that the client can handle. Currently maxBuf is being capped at
      CIFSMaxBufSize + the max headers size, and the two values are used
      somewhat interchangeably in the code.
      
      This makes little sense as these two values are not related at all.
      Separate them and make sure the code uses the right values in the right
      places.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      c974befa
  20. 03 8月, 2011 1 次提交
  21. 01 8月, 2011 1 次提交
  22. 13 7月, 2011 1 次提交
  23. 27 5月, 2011 1 次提交
  24. 19 5月, 2011 3 次提交
    • J
      cifs: keep BCC in little-endian format · 820a803f
      Jeff Layton 提交于
      This is the same patch as originally posted, just with some merge
      conflicts fixed up...
      
      Currently, the ByteCount is usually converted to host-endian on receive.
      This is confusing however, as we need to keep two sets of routines for
      accessing it, and keep track of when to use each routine. Munging
      received packets like this also limits when the signature can be
      calulated.
      
      Simplify the code by keeping the received ByteCount in little-endian
      format. This allows us to eliminate a set of routines for accessing it
      and we can now drop the *_le suffixes from the accessor functions since
      that's now implied.
      
      While we're at it, switch all of the places that read the ByteCount
      directly to use the get_bcc inline which should also clean up some
      unaligned accesses.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      820a803f
    • S
      consistently use smb_buf_length as be32 for cifs (try 3) · be8e3b00
      Steve French 提交于
             There is one big endian field in the cifs protocol, the RFC1001
             length, which cifs code (unlike in the smb2 code) had been handling as
             u32 until the last possible moment, when it was converted to be32 (its
             native form) before sending on the wire.   To remove the last sparse
             endian warning, and to make this consistent with the smb2
             implementation  (which always treats the fields in their
             native size and endianness), convert all uses of smb_buf_length to
             be32.
      
             This version incorporates Christoph's comment about
             using be32_add_cpu, and fixes a typo in the second
             version of the patch.
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      Signed-off-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      be8e3b00
    • S
      [CIFS] Use ecb des kernel crypto APIs instead of · 43988d76
      Steve French 提交于
       local cifs functions (repost)
      
      Using kernel crypto APIs for DES encryption during LM and NT hash generation
      instead of local functions within cifs.
      Source file smbdes.c is deleted sans four functions, one of which
      uses ecb des functionality provided by kernel crypto APIs.
      
      Remove function SMBOWFencrypt.
      
      Add return codes to various functions such as calc_lanman_hash,
      SMBencrypt, and SMBNTencrypt.  Includes fix noticed by Dan Carpenter.
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      CC: Dan Carpenter <error27@gmail.com>
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      43988d76
  25. 29 4月, 2011 2 次提交