1. 07 Oct, 2011 1 commit
  2. 19 Sep, 2011 1 commit
  3. 18 Aug, 2011 1 commit
  4. 01 Aug, 2011 5 commits
  5. 31 Jul, 2011 1 commit
  6. 19 Jul, 2011 1 commit
  7. 12 Jul, 2011 1 commit
  8. 11 Jul, 2011 1 commit
  9. 09 Jul, 2011 2 commits
  10. 07 Jul, 2011 1 commit
  11. 06 Jul, 2011 3 commits
  12. 01 Jul, 2011 1 commit
    • Jeff Layton's avatar
      cifs: set socket send and receive timeouts before attempting connect · ee1b3ea9
      Jeff Layton authored
      
      
      Benjamin S. reported that he was unable to suspend his machine while
      it had a cifs share mounted. The freezer caused this to spew when he
      tried it:
      
      -----------------------[snip]------------------
      PM: Syncing filesystems ... done.
      Freezing user space processes ... (elapsed 0.01 seconds) done.
      Freezing remaining freezable tasks ...
      Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0):
      cifsd         S ffff880127f7b1b0     0  1821      2 0x00800000
       ffff880127f7b1b0 0000000000000046 ffff88005fe008a8 ffff8800ffffffff
       ffff880127cee6b0 0000000000011100 ffff880127737fd8 0000000000004000
       ffff880127737fd8 0000000000011100 ffff880127f7b1b0 ffff880127736010
      Call Trace:
       [<ffffffff811e85dd>] ? sk_reset_timer+0xf/0x19
       [<ffffffff8122cf3f>] ? tcp_connect+0x43c/0x445
       [<ffffffff8123374e>] ? tcp_v4_connect+0x40d/0x47f
       [<ffffffff8126ce41>] ? schedule_timeout+0x21/0x1ad
       [<ffffffff8126e358>] ? _raw_spin_lock_bh+0x9/0x1f
       [<ffffffff811e81c7>] ? release_sock+0x19/0xef
       [<ffffffff8123e8be>] ? inet_stream_connect+0x14c/0x24a
       [<ffffffff8104485b>] ? autoremove_wake_function+0x0/0x2a
       [<ffffffffa02ccfe2>] ? ipv4_connect+0x39c/0x3b5 [cifs]
       [<ffffffffa02cd7b7>] ? cifs_reconnect+0x1fc/0x28a [cifs]
       [<ffffffffa02cdbdc>] ? cifs_demultiplex_thread+0x397/0xb9f [cifs]
       [<ffffffff81076afc>] ? perf_event_exit_task+0xb9/0x1bf
       [<ffffffffa02cd845>] ? cifs_demultiplex_thread+0x0/0xb9f [cifs]
       [<ffffffffa02cd845>] ? cifs_demultiplex_thread+0x0/0xb9f [cifs]
       [<ffffffff810444a1>] ? kthread+0x7a/0x82
       [<ffffffff81002d14>] ? kernel_thread_helper+0x4/0x10
       [<ffffffff81044427>] ? kthread+0x0/0x82
       [<ffffffff81002d10>] ? kernel_thread_helper+0x0/0x10
      
      Restarting tasks ... done.
      -----------------------[snip]------------------
      
      We do attempt to perform a try_to_freeze in cifs_reconnect, but the
      connection attempt itself seems to be taking longer than 20s to time
      out. The connect timeout is governed by the socket send and receive
      timeouts, so we can shorten that period by setting those timeouts
      before attempting the connect instead of after.
      
      Adam Williamson tested the patch and said that it seems to have fixed
      suspending on his laptop when a cifs share is mounted.
      Reported-by: default avatarBenjamin S <da_joind@gmx.net>
      Tested-by: default avatarAdam Williamson <awilliam@redhat.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      ee1b3ea9
  13. 24 Jun, 2011 5 commits
  14. 23 Jun, 2011 1 commit
  15. 22 Jun, 2011 1 commit
  16. 13 Jun, 2011 3 commits
    • Jeff Layton's avatar
      cifs: correctly handle NULL tcon pointer in CIFSTCon · 8d1bca32
      Jeff Layton authored
      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: default avatarMartijn Uffing <mp3project@sarijopen.student.utwente.nl>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      8d1bca32
    • Jeff Layton's avatar
      cifs: don't allow cifs_reconnect to exit with NULL socket pointer · 7fdbaa1b
      Jeff Layton authored
      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: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      7fdbaa1b
    • Pavel Shilovsky's avatar
      CIFS: Fix sparse error · cd51875d
      Pavel Shilovsky authored
      
      
      cifs_sb_master_tlink was declared as inline, but without a definition.
      Remove the declaration and move the definition up.
      Signed-off-by: default avatarPavel Shilovsky <piastryyy@gmail.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      cd51875d
  17. 08 Jun, 2011 1 commit
  18. 06 Jun, 2011 1 commit
  19. 03 Jun, 2011 1 commit
  20. 26 May, 2011 5 commits
  21. 25 May, 2011 1 commit
    • Jeff Layton's avatar
      cifs: clean up wsize negotiation and allow for larger wsize · f7910cbd
      Jeff Layton authored
      
      
      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: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-and-Tested-by: default avatarPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      f7910cbd
  22. 23 May, 2011 2 commits