1. 25 6月, 2011 5 次提交
  2. 24 6月, 2011 1 次提交
  3. 23 6月, 2011 1 次提交
  4. 14 6月, 2011 3 次提交
    • J
      cifs: correctly handle NULL tcon pointer in CIFSTCon · 8d1bca32
      Jeff Layton 提交于
      Long ago (in commit 00e485b0), I added some code to handle share-level
      passwords in CIFSTCon. That code ignored the fact that it's legit to
      pass in a NULL tcon pointer when connecting to the IPC$ share on the
      server.
      
      This wasn't really a problem until recently as we only called CIFSTCon
      this way when the server returned -EREMOTE. With the introduction of
      commit c1508ca2 however, it gets called this way on every mount, causing
      an oops when share-level security is in effect.
      
      Fix this by simply treating a NULL tcon pointer as if user-level
      security were in effect. I'm not aware of any servers that protect the
      IPC$ share with a specific password anyway. Also, add a comment to the
      top of CIFSTCon to ensure that we don't make the same mistake again.
      
      Cc: <stable@kernel.org>
      Reported-by: NMartijn Uffing <mp3project@sarijopen.student.utwente.nl>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      8d1bca32
    • J
      cifs: don't allow cifs_reconnect to exit with NULL socket pointer · 7fdbaa1b
      Jeff Layton 提交于
      It's possible for the following set of events to happen:
      
      cifsd calls cifs_reconnect which reconnects the socket. A userspace
      process then calls cifs_negotiate_protocol to handle the NEGOTIATE and
      gets a reply. But, while processing the reply, cifsd calls
      cifs_reconnect again.  Eventually the GlobalMid_Lock is dropped and the
      reply from the earlier NEGOTIATE completes and the tcpStatus is set to
      CifsGood. cifs_reconnect then goes through and closes the socket and sets the
      pointer to zero, but because the status is now CifsGood, the new socket
      is not created and cifs_reconnect exits with the socket pointer set to
      NULL.
      
      Fix this by only setting the tcpStatus to CifsGood if the tcpStatus is
      CifsNeedNegotiate, and by making sure that generic_ip_connect is always
      called at least once in cifs_reconnect.
      
      Note that this is not a perfect fix for this issue. It's still possible
      that the NEGOTIATE reply is handled after the socket has been closed and
      reconnected. In that case, the socket state will look correct but it no
      NEGOTIATE was performed on it be for the wrong socket. In that situation
      though the server should just shut down the socket on the next attempted
      send, rather than causing the oops that occurs today.
      
      Cc: <stable@kernel.org> # .38.x: fd88ce93: [CIFS] cifs: clarify the meaning of tcpStatus == CifsGood
      Reported-and-Tested-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      7fdbaa1b
    • P
      CIFS: Fix sparse error · cd51875d
      Pavel Shilovsky 提交于
      cifs_sb_master_tlink was declared as inline, but without a definition.
      Remove the declaration and move the definition up.
      Signed-off-by: NPavel Shilovsky <piastryyy@gmail.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      cd51875d
  5. 09 6月, 2011 1 次提交
  6. 06 6月, 2011 1 次提交
  7. 03 6月, 2011 1 次提交
  8. 27 5月, 2011 5 次提交
  9. 26 5月, 2011 1 次提交
    • J
      cifs: clean up wsize negotiation and allow for larger wsize · f7910cbd
      Jeff Layton 提交于
      Now that we can handle larger wsizes in writepages, fix up the
      negotiation of the wsize to allow for that. find_get_pages only seems to
      give out a max of 256 pages at a time, so that gives us a reasonable
      default of 1M for the wsize.
      
      If the server however does not support large writes via POSIX
      extensions, then we cap the wsize to (128k - PAGE_CACHE_SIZE). That
      gives us a size that goes up to the max frame size specified in RFC1001.
      
      Finally, if CAP_LARGE_WRITE_AND_X isn't set, then further cap it to the
      largest size allowed by the protocol (USHRT_MAX).
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-and-Tested-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f7910cbd
  10. 24 5月, 2011 4 次提交
  11. 19 5月, 2011 10 次提交
  12. 18 5月, 2011 1 次提交
  13. 03 5月, 2011 2 次提交
  14. 29 4月, 2011 1 次提交
  15. 22 4月, 2011 1 次提交
  16. 12 4月, 2011 2 次提交
    • S
      [CIFS] Warn on requesting default security (ntlm) on mount · d9b94201
      Steve French 提交于
      Warn once if default security (ntlm) requested. We will
      update the default to the stronger security mechanism
      (ntlmv2) in 2.6.41.  Kerberos is also stronger than
      ntlm, but more servers support ntlmv2 and ntlmv2
      does not require an upcall, so ntlmv2 is a better
      default.
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      CC: Suresh Jayaraman <sjayaraman@suse.de>
      Reviewed-by: NShirish Pargaonkar <shirishp@us.ibm.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      d9b94201
    • S
      [CIFS] cifs: clarify the meaning of tcpStatus == CifsGood · fd88ce93
      Steve French 提交于
      When the TCP_Server_Info is first allocated and connected, tcpStatus ==
      CifsGood means that the NEGOTIATE_PROTOCOL request has completed and the
      socket is ready for other calls. cifs_reconnect however sets tcpStatus
      to CifsGood as soon as the socket is reconnected and the optional
      RFC1001 session setup is done. We have no clear way to tell the
      difference between these two states, and we need to know this in order
      to know whether we can send an echo or not.
      
      Resolve this by adding a new statusEnum value -- CifsNeedNegotiate. When
      the socket has been connected but has not yet had a NEGOTIATE_PROTOCOL
      request done, set it to this value. Once the NEGOTIATE is done,
      cifs_negotiate_protocol will set tcpStatus to CifsGood.
      
      This also fixes and cleans the logic in cifs_reconnect and
      cifs_reconnect_tcon. The old code checked for specific states when what
      it really wants to know is whether the state has actually changed from
      CifsNeedReconnect.
      Reported-and-Tested-by: NJG <jg@cms.ac>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      fd88ce93