All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Benjamin Coddington <bcodding@redhat.com>
Cc: Olga Kornievskaia <aglo@umich.edu>,
	Jeff Layton <jlayton@kernel.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Chuck Lever III <chuck.lever@oracle.com>
Subject: Re: Is this nfsd kernel oops known?
Date: Sat, 10 Sep 2022 22:14:02 +0100	[thread overview]
Message-ID: <Yxz+GhK7nWKcBLcI@ZenIV> (raw)
In-Reply-To: <25AF9743-A2A2-4AFE-9123-BAD3C8F17655@redhat.com>

On Wed, Sep 07, 2022 at 08:52:46AM -0400, Benjamin Coddington wrote:
> On 7 Sep 2022, at 0:58, Chuck Lever III wrote:
> 
> > > On Sep 6, 2022, at 3:12 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> > > 
> > > On Tue, Sep 6, 2022 at 2:28 PM Benjamin Coddington
> > > <bcodding@redhat.com> wrote:
> > > > 
> > > > On 1 Sep 2022, at 21:27, Olga Kornievskaia wrote:
> > > > 
> > > > > Thanks Chuck. I first, based on a hunch, narrowed down that it's
> > > > > coming from Al Viro's merge commit. Then I git bisected his
> > > > > 32patches
> > > > > to the following commit f0f6b614f83dbae99d283b7b12ab5dd2e04df979
> > > > 
> > > > No crash for me after reverting
> > > > f0f6b614f83dbae99d283b7b12ab5dd2e04df979.
> > > 
> > > I second that. No crash after a revert here.
> > 
> > I bisected the new xfstests failures to the same commit:
> > 
> > f0f6b614f83dbae99d283b7b12ab5dd2e04df979 is the first bad commit
> > commit f0f6b614f83dbae99d283b7b12ab5dd2e04df979
> > Author: Al Viro <viro@zeniv.linux.org.uk>
> > Date:   Thu Jun 23 17:21:37 2022 -0400
> > 
> >     copy_page_to_iter(): don't split high-order page in case of
> > ITER_PIPE
> > 
> >     ... just shove it into one pipe_buffer.
> > 
> >     Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> > 
> >  lib/iov_iter.c | 21 ++++++---------------
> >  1 file changed, 6 insertions(+), 15 deletions(-)
> > 
> 
> I've been reliably reproducing this on generic/551 on xfs.  In the case
> where it crashes, rqstp->rq_res.page_base is positive multiple of PAGE_SIZE
> after getting set in nfsd_splice_actor(), and that with page_len overruns
> the 256 pages we have.
> 
> With f0f6b614f83d reverted, rqstp->rq_res.page_base is always zero.
> 
> After 47b7fcae419dc and f0f6b614f83d, buf->offset in nfsd_splice_actor can
> be a positive multiple of PAGE_SIZE, whereas before it was always just the
> offset into the page.
> 
> Something like this might fix it up:
> 
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 9f486b788ed0..d62963f36f03 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -849,7 +849,7 @@ nfsd_splice_actor(struct pipe_inode_info *pipe, struct
> pipe_buffer *buf,
> 
>         svc_rqst_replace_page(rqstp, buf->page);
>         if (rqstp->rq_res.page_len == 0)
> -               rqstp->rq_res.page_base = buf->offset;
> +               rqstp->rq_res.page_base = buf->offset % PAGE_SIZE;
>         rqstp->rq_res.page_len += sd->len;
>         return sd->len;
>  }
> 
> .. but we should check with Al about whether this needs to be fixed over in
> copy_page_to_iter_pipe(),  since I don't think pipe_buffer offset should be
> greater than PAGE_SIZE.
> 
> Al, any thoughts?

pipe_buffer offsets in general can be greater than PAGE_SIZE.  What's more,
buffer *size* can be greater than PAGE_SIZE - it really can contain more
than PAGE_SIZE worth of data.  In that case the page is a compound one, of
course.

Regression is the combination of "splice from regular file to pipe hadn't
produced that earlier, now it does" and "nfsd never needed to handle that".

I don't believe that fix is correct.  *IF* you can't deal with compound
page in sunrpc, you need a loop going by subpages in nfsd_splice_actor(),
similar to one that used to be in copy_page_to_iter().  Could you try
the following:

nfsd_splice_actor(): handle compound pages

pipe_buffer might refer to a compound page (and contain more than a PAGE_SIZE
worth of data).  Theoretically it had been possible since way back, but
nfsd_splice_actor() hadn't run into that until copy_page_to_iter() change.
Fortunately, the only thing that changes for compound pages is that we
need to stuff each relevant subpage in and convert the offset into offset
in the first subpage.

Hopefully-fixes: f0f6b614f83d "copy_page_to_iter(): don't split high-order page in case of ITER_PIPE"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 9f486b788ed0..b16aed158ba6 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -846,10 +846,14 @@ nfsd_splice_actor(struct pipe_inode_info *pipe, struct pipe_buffer *buf,
 		  struct splice_desc *sd)
 {
 	struct svc_rqst *rqstp = sd->u.data;
-
-	svc_rqst_replace_page(rqstp, buf->page);
-	if (rqstp->rq_res.page_len == 0)
-		rqstp->rq_res.page_base = buf->offset;
+	struct page *page = buf->page;	// may be a compound one
+	unsigned offset = buf->offset;
+
+	page += offset / PAGE_SIZE;
+	for (int i = sd->len; i > 0; i -= PAGE_SIZE)
+		svc_rqst_replace_page(rqstp, page++);
+	if (rqstp->rq_res.page_len == 0)	// first call
+		rqstp->rq_res.page_base = offset % PAGE_SIZE;
 	rqstp->rq_res.page_len += sd->len;
 	return sd->len;
 }

  reply	other threads:[~2022-09-10 21:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 17:14 Is this nfsd kernel oops known? Olga Kornievskaia
2022-08-30 17:49 ` Jeff Layton
2022-08-30 18:22   ` Olga Kornievskaia
2022-08-30 18:26     ` Chuck Lever III
2022-08-30 18:33       ` Olga Kornievskaia
2022-08-30 18:41         ` Chuck Lever III
2022-08-30 18:54           ` Olga Kornievskaia
2022-09-01 13:51   ` Olga Kornievskaia
2022-09-01 14:33     ` Benjamin Coddington
2022-09-01 20:08     ` Chuck Lever III
2022-09-02  1:27       ` Olga Kornievskaia
2022-09-02 20:58         ` Benjamin Coddington
2022-09-02 21:13           ` Chuck Lever III
2022-09-03  0:38             ` Benjamin Coddington
2022-09-03  3:34               ` Olga Kornievskaia
2022-09-03 16:41                 ` Chuck Lever III
2022-09-06 18:28         ` Benjamin Coddington
2022-09-06 19:12           ` Olga Kornievskaia
2022-09-07  4:58             ` Chuck Lever III
2022-09-07 12:52               ` Benjamin Coddington
2022-09-10 21:14                 ` Al Viro [this message]
2022-09-10 21:21                   ` Chuck Lever III
2022-09-10 22:13                     ` Al Viro
2022-09-10 22:35                       ` Chuck Lever III
2022-09-11  3:51                         ` Al Viro
2022-09-11 10:47                   ` Benjamin Coddington
2022-09-11 18:36                   ` Chuck Lever III
2022-09-11 19:39                     ` Al Viro
2022-09-12 18:45                       ` Benjamin Coddington
2022-09-13  2:43                         ` [pull request] vfs.git: fix for nfsd regression caused by iov_iter stuff Al Viro
2022-09-13 13:16                           ` pr-tracker-bot
2022-09-03  4:25     ` Is this nfsd kernel oops known? NeilBrown

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=Yxz+GhK7nWKcBLcI@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=aglo@umich.edu \
    --cc=bcodding@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --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.