Re: [PATCH 02/13] mm/filemap: convert fault and readahead logic to use vma_flags_t

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Sun, Nov 08, 2026 at 03:42:36PM +0800, Barry Song wrote:
> On Sun, Nov 8, 2026 at 3:20 PM Barry Song <baohua@kernel.org> wrote:
> >
> > On Fri, Nov 6, 2026 at 7:53 PM Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> > [...]
> > > > --
> > > > 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