All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Benjamin Coddington <bcodding@redhat.com>
Cc: Anna Schumaker <anna.schumaker@netapp.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] SUNRPC: Fix another issue with MIC buffer space
Date: Fri, 15 Nov 2019 09:44:15 -0500	[thread overview]
Message-ID: <29A5981F-5109-489E-913E-B80B6252B115@oracle.com> (raw)
In-Reply-To: <F23BF77A-5CB4-455F-8F23-C92EE2AB5212@oracle.com>



> On Nov 15, 2019, at 9:41 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> 
> 
>> On Nov 15, 2019, at 9:35 AM, Benjamin Coddington <bcodding@redhat.com> wrote:
>> 
>> On 15 Nov 2019, at 8:39, Chuck Lever wrote:
>> 
>>> xdr_shrink_pagelen() BUG's when @len is larger than buf->page_len.
>>> This can happen when xdr_buf_read_mic() is given an xdr_buf with
>>> a small page array (like, only a few bytes).
>> 
>> Hi Chuck,
>> 
>> Seems like a bug in xdr_buf_read_mic to me, but I'm not seeing how this can
>> happen.. unless perhaps xdr->page_len is 0?  Or maybe xdr_shift_buf has bug?
> 
> rpc_prepare_reply_pages() sets buf->page_len to the args->count of the
> NFS READ request. For really small READs, this can be 2, or 12, or
> anything smaller than the MIC length.
> 
> 
>> I'd prefer to keep the BUG_ON.
> 
> Linus would prefer not to. :-)
> 
> 
>> How can I reproduce it?
> 
> I've been using the git regression suite with NFSv4.1 and krb5i.
> I run it with 12 threads.

And I enable disconnect injection. Yer basic torture test.


>> diff --git a/net/sunrpc/xdr.c b/net/sunrpc/xdr.c
>> index 14ba9e72a204..71d754fc780e 100644
>> --- a/net/sunrpc/xdr.c
>> +++ b/net/sunrpc/xdr.c
>> @@ -1262,6 +1262,8 @@ int xdr_buf_read_mic(struct xdr_buf *buf, struct xdr_netobj *mic, unsigned int o
>>       if (offset < boundary && (offset + mic->len) > boundary)
>>               xdr_shift_buf(buf, boundary - offset);
>> 
>> +       trace_printk("boundary %d, offset %d, page_len %d\n", boundary, offset, buf->page_len);
>> +
>>       /* Is the mic partially in the pages? */
>>       boundary += buf->page_len;
>>       if (offset < boundary && (offset + mic->len) > boundary)
>> 
>> ^^ that should be enough for me to try to figure out what's doing wrong.
>> 
>> Ben
>> 
> 
> --
> Chuck Lever

--
Chuck Lever




  reply	other threads:[~2019-11-15 14:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-15 13:39 [PATCH] SUNRPC: Fix another issue with MIC buffer space Chuck Lever
2019-11-15 14:35 ` Benjamin Coddington
2019-11-15 14:41   ` Chuck Lever
2019-11-15 14:44     ` Chuck Lever [this message]
2019-11-15 14:51       ` Benjamin Coddington
2019-11-15 14:54         ` Chuck Lever
2019-11-15 15:51   ` Chuck Lever
2019-11-15 17:31     ` Benjamin Coddington
2019-11-15 17:34       ` Chuck Lever
2019-11-15 18:04         ` Benjamin Coddington
2019-11-18 15:24 Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29A5981F-5109-489E-913E-B80B6252B115@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=anna.schumaker@netapp.com \
    --cc=bcodding@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.