[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aJuudyp8VUPvIbjF@codewreck.org>
Date: Wed, 13 Aug 2025 06:13:27 +0900
From: asmadeus@...ewreck.org
To: David Howells <dhowells@...hat.com>
Cc: "Matthew Wilcox (Oracle)" <willy@...radead.org>,
Christian Brauner <brauner@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Maximilian Bosch <maximilian@...sch.me>,
Ryan Lahfa <ryan@...fa.xyz>, Christian Theune <ct@...ingcircus.io>,
Arnout Engelen <arnout@...t.net>, linux-kernel@...r.kernel.org,
linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH 1/2] iov_iter: iterate_folioq: fix handling of offset >=
folio size
David Howells wrote on Tue, Aug 12, 2025 at 10:34:17AM +0100:
> asmadeus@...ewreck.org wrote:
>
> > 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?
>
> We should handle both cases. I think the other iteration functions
> will. iov_iter_extractg_folioq_pages(), for example, wraps it in a
> conditional:
>
> if (offset < fsize) {
> part = umin(part, umin(maxsize - extracted, fsize - offset));
> i->count -= part;
> i->iov_offset += part;
> extracted += part;
>
> p[nr++] = folio_page(folio, offset / PAGE_SIZE);
> }
That's not what I pointed out just now; it doesn't check either if there
is no slot left
For example, an iov_iter with nr_slots = 4, slot = 4, folioq->next =
NULL will happily trod on folioq->vec.folios[4] (folioq_folio(folioq,
slot)) which is invalid
--
Dominique Martinet | Asmadeus
Powered by blists - more mailing lists