On Sun, Nov 08, 2026 at 03:42:36PM +0800, Barry Song wrote:
On Sun, Nov 8, 2026 at 3:20 PM Barry Song [off-list ref] wrote:
quoted
On Fri, Nov 6, 2026 at 7:53 PM Lorenzo Stoakes (ARM) [off-list ref] wrote:
[...]
quoted
quoted
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105-late-2026-vma-flags-v1-0-0d3cd15ab75f@kernel.org?part=2
It seems these are valid, oops!
Andrew suggested a fix off-list, and I agreed to this as an in-place fixup to
avoid respin.
I have also updated the series locally to reflect this change:
Seems like a reasonable fix. maybe_unlock_mmap_for_io()
could have released mmap_lock, leaving the VMA
unprotected. but ra->size *= 2 is still going there no matter
if the vma has disappeared
For the original patch combined with the fix,
Reviewed-by: Barry Song <baohua@kernel.org>
BTW, one question is whether mmap-based readahead is
still worthwhile if the VMA is actually gone after we
release mmap_lock (or the VMA lock). Perhaps we don't
need to continue readahead in that case.
However, we don't have a reliable way to know whether
the VMA is really gone until the page fault is retried.
We release the lock to perform readahead, so in this
racy case, readahead might be happening for a VMA that
is being removed.
I'm not challenging this patch, just leaving a note
to think about later :-)
I suspect it's one of those 'not worth checking' situations, VMAs can come
and go at will at any time and theoretically you can do useless work, as
long as that's mostly not the case I think we're OK.
And in general I think these code paths need significant rework before we
revisit stuff like this, we always pay a tax for code complexity!
--
Cheers, Lorenzo