Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 2月, 2013 1 次提交
  3. 21 12月, 2012 1 次提交
  5. 12 12月, 2012 3 次提交
    • J
      cifs: parse the device name into UNC and prepath · d387a5c5
      由 Jeff Layton 提交于 
      This should fix a regression that was introduced when the new mount
option parser went in. Also, when the unc= and prefixpath= options
are provided, check their values against the ones we parsed from
the device string. If they differ, then throw a warning that tells
the user that we're using the values from the unc= option for now,
but that that will change in 3.10.

Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>
      d387a5c5
    • J
      cifs: fix up handling of prefixpath= option · 839db3d1
      由 Jeff Layton 提交于 
      Currently the code takes care to ensure that the prefixpath has a
leading '/' delimiter. What if someone passes us a prefixpath with a
leading '\\' instead? The code doesn't properly handle that currently
AFAICS.

Let's just change the code to skip over any leading delimiter character
when copying the prepath. Then, fix up the users of the prepath option
to prefix it with the correct delimiter when they use it.

Also, there's no need to limit the length of the prefixpath to 1k. If
the server can handle it, why bother forbidding it?

Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>
      839db3d1
    • J
      cifs: clean up handling of unc= option · 62a1a439
      由 Jeff Layton 提交于 
      Make sure we free any existing memory allocated for vol->UNC, just in
case someone passes in multiple unc= options.

Get rid of the check for too long a UNC. The check for >300 bytes seems
arbitrary. We later copy this into the tcon->treeName, for instance and
it's a lot shorter than 300 bytes.

Eliminate an extra kmalloc and copy as well. Just set the vol->UNC
directly with the contents of match_strdup.

Establish that the UNC should be stored with '\\' delimiters. Use
convert_delimiter to change it in place in the vol->UNC.

Finally, move the check for a malformed UNC into
cifs_parse_mount_options so we can catch that situation earlier.

Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>
      62a1a439
  7. 10 12月, 2012 1 次提交
  9. 06 12月, 2012 8 次提交
  11. 08 10月, 2012 1 次提交
  13. 02 10月, 2012 1 次提交
  15. 25 9月, 2012 6 次提交
  17. 25 7月, 2012 8 次提交
  19. 24 7月, 2012 8 次提交
  21. 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
  23. 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