> On Apr 7, 2022, at 3:23 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote:
>
> On Thu, 2022-04-07 at 14:46 -0400, trondmy@xxxxxxxxxx wrote:
>> From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
>>
>> The allocation is done with GFP_KERNEL, but it could still fail in a
>> low
>> memory situation.
>>
>> Fixes: 4a85a6a3320b ("SUNRPC: Handle TCP socket sends with
>> kernel_sendpage() again")
>> Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
>> ---
>> net/sunrpc/svcsock.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>> index 478f857cdaed..6ea3d87e1147 100644
>> --- a/net/sunrpc/svcsock.c
>> +++ b/net/sunrpc/svcsock.c
>> @@ -1096,7 +1096,9 @@ static int svc_tcp_sendmsg(struct socket *sock,
>> struct xdr_buf *xdr,
>> int ret;
>>
>> *sentp = 0;
>> - xdr_alloc_bvec(xdr, GFP_KERNEL);
>> + ret = xdr_alloc_bvec(xdr, GFP_KERNEL);
>> + if (ret < 0)
>> + return ret;
>>
>> ret = kernel_sendmsg(sock, &msg, &rm, 1, rm.iov_len);
>> if (ret < 0)
>
>
> Chuck,
>
> Do you mind if I send this and the 8/8 as part of the client pull
> request? I saw this while I was digging through the code and separating
> out the client and server uses of xdr_alloc_bvec().
I browsed through these a few minutes ago. I don't see any technical
issues. But as you're listed as a maintainer of the SUNRPC code, I
didn't think I needed to give explicit permission.
--
Chuck Lever
