On Sat, Sep 10, 2022 at 10:35:52PM +0000, Chuck Lever III wrote: > > > > On Sep 10, 2022, at 6:13 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > 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? ;-) > > Well, no, since you just added it :-) I meant pre-existing > documentation of the API. I take your remark as polite > encouragement to go and look for it, because this is an > area where I need deeper understanding. Not really - quality of documentation aside, it's a combination of splice from sockets being capable of stuffing skb fragments into destination pipe and skb allocations using compound pages. E.g. AF_UNIX sendmsg() on a large datagram will result in that. socketpair(), then such sendmsg() on one end, splice() from another and there you go - references to compound pages ending up in pipe buffers... nfsd_splice_read() does file-to-pipe splice (into internal pipe) + feeding the contents of that pipe into nfsd_splice_actor(); the new part here is that file-to-pipe splice from regular file can end up with the thing that had always been possible for file-to-pipe splice from sockets...
