1. 24 7月, 2012 2 次提交
  2. 17 7月, 2012 1 次提交
    • J
      cifs: on CONFIG_HIGHMEM machines, limit the rsize/wsize to the kmap space · 3ae629d9
      Jeff Layton 提交于
      We currently rely on being able to kmap all of the pages in an async
      read or write request. If you're on a machine that has CONFIG_HIGHMEM
      set then that kmap space is limited, sometimes to as low as 512 slots.
      
      With 512 slots, we can only support up to a 2M r/wsize, and that's
      assuming that we can get our greedy little hands on all of them. There
      are other users however, so it's possible we'll end up stuck with a
      size that large.
      
      Since we can't handle a rsize or wsize larger than that currently, cap
      those options at the number of kmap slots we have. We could consider
      capping it even lower, but we currently default to a max of 1M. Might as
      well allow those luddites on 32 bit arches enough rope to hang
      themselves.
      
      A more robust fix would be to teach the send and receive routines how
      to contend with an array of pages so we don't need to marshal up a kvec
      array at all. That's a fairly significant overhaul though, so we'll need
      this limit in place until that's ready.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NJian Li <jiali@redhat.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      3ae629d9
  3. 04 7月, 2012 1 次提交
    • J
      cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize · ec01d738
      Jeff Layton 提交于
      When the server doesn't advertise CAP_LARGE_READ_X, then MS-CIFS states
      that you must cap the size of the read at the client's MaxBufferSize.
      Unfortunately, testing with many older servers shows that they often
      can't service a read larger than their own MaxBufferSize.
      
      Since we can't assume what the server will do in this situation, we must
      be conservative here for the default. When the server can't do large
      reads, then assume that it can't satisfy any read larger than its
      MaxBufferSize either.
      
      Luckily almost all modern servers can do large reads, so this won't
      affect them. This is really just for older win9x and OS/2 era servers.
      Also, note that this patch just governs the default rsize. The admin can
      always override this if he so chooses.
      
      Cc: <stable@vger.kernel.org> # 3.2
      Reported-by: NDavid H. Durgee <dhdurgee@acm.org>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteven French <sfrench@w500smf.(none)>
      ec01d738
  4. 13 6月, 2012 1 次提交
    • S
      cifs: fix parsing of password mount option · e73f843a
      Suresh Jayaraman 提交于
      The double delimiter check that allows a comma in the password parsing code is
      unconditional. We set "tmp_end" to the end of the string and we continue to
      check for double delimiter. In the case where the password doesn't contain a
      comma we end up setting tmp_end to NULL and eventually setting "options" to
      "end". This results in the premature termination of the options string and hence
      the values of UNCip and UNC are being set to NULL. This results in mount failure
      with "Connecting to DFS root not implemented yet" error.
      
      This error is usually not noticable as we have password as the last option in
      the superblock mountdata. But when we call expand_dfs_referral() from
      cifs_mount() and try to compose mount options for the submount, the resulting
      mountdata will be of the form
      
         ",ver=1,user=foo,pass=bar,ip=x.x.x.x,unc=\\server\share"
      
      and hence results in the above error. This bug has been seen with older NAS
      servers running Samba 3.0.24.
      
      Fix this by moving the double delimiter check inside the conditional loop.
      
      Changes since -v1
      
         - removed the wrong strlen() micro optimization.
      Signed-off-by: NSuresh Jayaraman <sjayaraman@suse.com>
      Acked-by: NSachin Prabhu <sprabhu@redhat.com>
      Cc: stable@vger.kernel.org [3.1+]
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      e73f843a
  5. 02 6月, 2012 2 次提交
  6. 23 5月, 2012 4 次提交
  7. 17 5月, 2012 6 次提交
  8. 04 5月, 2012 1 次提交
  9. 02 5月, 2012 2 次提交
  10. 25 4月, 2012 1 次提交
  11. 13 4月, 2012 1 次提交
  12. 12 4月, 2012 1 次提交
  13. 04 4月, 2012 2 次提交
  14. 28 3月, 2012 1 次提交
  15. 24 3月, 2012 6 次提交
  16. 22 3月, 2012 4 次提交
  17. 20 3月, 2012 1 次提交
  18. 08 2月, 2012 2 次提交
  19. 31 1月, 2012 1 次提交
    • R
      cifs: fix printk format warnings · 000f9bb8
      Randy Dunlap 提交于
      Fix printk format warnings for ssize_t variables:
      
      fs/cifs/connect.c:2145:3: warning: format '%ld' expects type 'long int', but argument 3 has type 'ssize_t'
      fs/cifs/connect.c:2152:3: warning: format '%ld' expects type 'long int', but argument 3 has type 'ssize_t'
      fs/cifs/connect.c:2160:3: warning: format '%ld' expects type 'long int', but argument 3 has type 'ssize_t'
      fs/cifs/connect.c:2170:3: warning: format '%ld' expects type 'long int', but argument 3 has type 'ssize_t'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Cc:	linux-cifs@vger.kernel.org
      000f9bb8