From: asmadeus@codewreck.org
To: David Howells <dhowells@redhat.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Maximilian Bosch <maximilian@mbosch.me>,
Ryan Lahfa <ryan@lahfa.xyz>,
Christian Theune <ct@flyingcircus.io>,
Arnout Engelen <arnout@bzzt.net>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] iov_iter: iterate_folioq: fix handling of offset >= folio size
Date: Tue, 12 Aug 2025 06:37:42 +0900 [thread overview]
Message-ID: <aJpipiVk0zneTxXl@codewreck.org> (raw)
In-Reply-To: <385673.1754923063@warthog.procyon.org.uk>
David Howells wrote on Mon, Aug 11, 2025 at 03:37:43PM +0100:
> Dominique Martinet via B4 Relay wrote:
> > It's apparently possible to get an iov forwarded all the way up to the
>
> By "forwarded" I presume you mean "advanced"?
Thanks, swapped words in v2
> > This should have been because we're only in the 2nd slot and there's
> > another one after this, but iterate_folioq should not try to map a
> > folio that skips the whole size, and more importantly part here does
> > not end up zero (because 'PAGE_SIZE - skip % PAGE_SIZE' ends up
> > PAGE_SIZE and not zero..), so skip forward to the "advance to next
> > folio" code.
>
> Note that things get complicated because folioqs form a segmented list that
> can be under construction as it advances. So if there's no next folioq
> segment at the time you advance to the end of the current one, it will end up
> parked at the end of the last folio or with slot==nr_slots because there's
> nowhere for it to advance to.
Hmm, I've already sent a v2 with other things fixed but now you made me
look at the "we're at the end of the iov_iter" case I think this won't
work well either?
folioq_folio() always returns something, and the advance code only
advances if folioq->next is set and doesn't bail out if it's unset.
There should be a `if (slot == folioq_nr_slots(folioq)) break` check
somewhere as well? Or is the iov_iter guaranteed to always 1/ have some
data and 2/ either be big enough or have remaining data in a step?
I can believe the former but wouldn't trust the later...
> Note that extract_folioq_to_sg() already does this as does
> iov_iter_extract_folioq_pages().
Yes we're not quite consistent here, some functions like the plain
iov_iter_advance will get you on an invalid slot to check for
folioq->next on next invocations while others point at the end of the
last folio in the queue (like iov_iter_extract_folioq_pages(), and
iov_folioq_get_pages() before patch 2);
I think either pattern is valid; I've changed iov_folioq_get_pages()
because it was a bit weird to have an iov_iter with offset > count and
iov_iter_advance wouldn't do this, but I agree either should work, we
just probably want to be more consistent.
Thanks,
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2025-08-11 21:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 7:39 [PATCH 0/2] iterate_folioq bug when offset==size (Was: [REGRESSION] 9pfs issues on 6.12-rc1) Dominique Martinet
2025-08-11 7:39 ` Dominique Martinet via B4 Relay
2025-08-11 7:39 ` [PATCH 1/2] iov_iter: iterate_folioq: fix handling of offset >= folio size Dominique Martinet
2025-08-11 7:39 ` Dominique Martinet via B4 Relay
2025-08-11 14:37 ` David Howells
2025-08-11 21:37 ` asmadeus [this message]
2025-08-12 9:34 ` David Howells
2025-08-12 21:13 ` asmadeus
2025-08-11 18:55 ` kernel test robot
2025-08-13 5:16 ` Nathan Chancellor
2025-08-13 5:34 ` Dominique Martinet
2025-08-13 13:39 ` Andy Shevchenko
2025-08-13 13:45 ` Dominique Martinet
2025-08-13 13:52 ` Andy Shevchenko
2025-08-14 1:14 ` Dominique Martinet
2025-08-13 23:04 ` Paul E. McKenney
2025-08-13 13:49 ` David Howells
2025-08-11 7:39 ` [PATCH 2/2] iov_iter: iov_folioq_get_pages: don't leave empty slot behind Dominique Martinet
2025-08-11 7:39 ` Dominique Martinet via B4 Relay
2025-08-11 13:13 ` Arnout Engelen
2025-08-11 14:38 ` David Howells
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=aJpipiVk0zneTxXl@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=akpm@linux-foundation.org \
--cc=arnout@bzzt.net \
--cc=brauner@kernel.org \
--cc=ct@flyingcircus.io \
--cc=dhowells@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maximilian@mbosch.me \
--cc=ryan@lahfa.xyz \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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.