Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 10 Sep 2022 23:13:10 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Benjamin Coddington <bcodding@redhat.com>,
        Olga Kornievskaia <aglo@umich.edu>,
        Jeff Layton <jlayton@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Is this nfsd kernel oops known?
Message-ID: <Yx0L9p4VMH2v2tBX@ZenIV>
References: <5c423fdf25e6cedb2dcdbb9c8665d6a9ab4ad4b1.camel@kernel.org>
 <CAN-5tyEOTVDhR6FgP7nPVon76qhKkexaWB8AJ_iBVTp6iYOk1g@mail.gmail.com>
 <11BEA7FE-4CBC-4E5C-9B68-A0310CF1F3BE@oracle.com>
 <CAN-5tyHOugPeTsu+gBJ1tkqawyQDkfHXrO=vQ6vZTTzWJWTqGA@mail.gmail.com>
 <D0A6E504-F2C2-4A5F-BC51-FD3D88A790F0@redhat.com>
 <CAN-5tyHYH7ODzmTK=Maa3NZOSxfcE0mfaWY11+n2htQpya869g@mail.gmail.com>
 <EE9C1D1C-AA5B-48BC-9E3A-8A4523456AEE@oracle.com>
 <25AF9743-A2A2-4AFE-9123-BAD3C8F17655@redhat.com>
 <Yxz+GhK7nWKcBLcI@ZenIV>
 <9D6CDF68-6B12-44DE-BC01-3BD0251E7F94@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9D6CDF68-6B12-44DE-BC01-3BD0251E7F94@oracle.com>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Sat, Sep 10, 2022 at 09:21:11PM +0000, Chuck Lever III wrote:

> It's also possible that recent simplifications I've done to the splice
> read actor accidentally removed the ability to deal with compound pages.
> You might want to review the commit history of nfsd_splice_actor() to
> see if there is an historic version that would behave correctly with
> the new copy_page_to_iter().

Nah, that's unrelated...

> Is the need to deal with CompoundPage documented somewhere? If not,
> perhaps nfsd_splice_actor() could mention it so that overzealous
> maintainers don't break it again.

> > +	struct page *page = buf->page;	// may be a compound one

Does that qualify? ;-)

FWIW, there's a separate problem in that thing - it assumes that
pipe_buffer boundaries will end up PAGE_SIZE-aligned.  Usually
that's going to be true, but foofs_splice_read() is not required to
maintain that.  E.g. it might be working in terms of chunks
used by weird protocol used by foofs, with e.g. 1024-byte payloads
+ 300-odd bytes of framing/checskums/whatnot.  In that case it
might do 1024 bytes per pipe_buffer, with non-zero offset in page
in each of them; normal read()/splice()/etc. would work just fine
with that, but for nfsd_splice_actor() results would not be
nice.

AFAICS, sunrpc assumes that we have several pages, offset in the
first one and total size; no provisions exist for e.g. 5Kb of
data scattered in 5 chunks over 5 pages.  Correct?