]> git.karo-electronics.de Git - karo-tx-linux.git/commit
cifs: on CONFIG_HIGHMEM machines, limit the rsize/wsize to the kmap space
authorJeff Layton <jlayton@redhat.com>
Wed, 11 Jul 2012 13:09:35 +0000 (09:09 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 29 Jul 2012 15:04:18 +0000 (08:04 -0700)
commitc82cd13737cfab6cb9d1b31e624896e627f9c9e4
treebf85c3373040be2cecfb9574575afb9a8aa1c950
parentf952e137849253c0584a60cc2d73a220d9a091f8
cifs: on CONFIG_HIGHMEM machines, limit the rsize/wsize to the kmap space

commit 3ae629d98bd5ed77585a878566f04f310adbc591 upstream.

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.

Reported-by: Jian Li <jiali@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/cifs/connect.c