Linux: Restrict # of cbrs we allocate at once

Linux: Restrict # of cbrs we allocate at once

With commit a309e274632993c5aeec04c6e090f5ac95837a40, we changed the
number of CBRs that we allocate in a chunk from 300 to 1024. However,
this change takes the amount of memory requried to allocate a chunk
of CBRs above PAGE_SIZE on Linux. This changes the allocator that we
use from kmalloc to vmalloc. Whilst we can, and do, prevent kmalloc
from flushing filesystem pages when we invoke it, we don't have a
similar level of control over vmalloc. 1.6 only: limit it back to 300
elsewhere.

In one reported case, clients deadlock whilst attempting to allocate
this memory, in a call stack that looks something like:

  afs_Daemon -> afs_ShakeLooseVCaches -> osi_TryEvictVCache
      -> afs_FlushVCache -> afs_QueueVCB -> afs_AllocCBR
      -> osi_linux_alloc -> ... -> __vmalloc_node -> ...
      -> try_to_free_pages

This is probably because we end up deadlocking in the writeback
invoked by try_to_free_pages, likely due to locks which are held
by ShakeLooseVCaches.

As a quick fix for the problem, make sure that the memory we
allocate always fits within a page, so we always use kmalloc for
it.

FIXES 129751

Reviewed-on: http://gerrit.openafs.org/4510
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
(cherry picked from commit 3cb97cdaa867b0d9fef84c683251a0a8f59a1519)

Change-Id: I28a480788271eac1b69fb9704bed5c286be2c4c5
Reviewed-on: http://gerrit.openafs.org/4555
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>