Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf

On Oct 25, 2016, at 15:59, Fields Bruce James [off-list ref] wrote:

On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:

quoted

quoted

On Oct 25, 2016, at 14:45, J. Bruce Fields [off-list ref] wrote:

From: "J. Bruce Fields" <redacted>

As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
among other callers, passes it memory on the stack.

We only need a scatterlist to pass this to the crypto code, and it seems
like overkill to require kmalloc'd memory just to encrypt a few bytes,
but for now this seems the best fix.

Note many of these callers are in the NFS write paths, so we shouldn't
really be allocating GFP_KERNEL.  But we already have other allocations
in these code paths.  A larger redesign may be necessary to allow
allocations to be done earlier.

NACK…  I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….

OK.  Any disadvantage to keeping this patch with just GFP_NOFS
allocations everywhere that might be in the write path?

It’s what we have to do everywhere else in the RPC client, so I can’t see why it should be a problem.

��칻
�&�~�&���+-��ݶ��w��˛���m�b��g~ȧ���ܨ}���Ơz�&j:+v����n�r��6;靫3��\
nnX��f�z��2�ޙ���&�)ߡ�a����
�G���h��j:+v���w�٥