Re: [PATCH v2] mm/vma: avoid spurious write locks when mm->mm_lock_seq overflows

[Lorenzo Stoakes (ARM)]

On Mon, Oct 19, 2026 at 07:32:01AM -0700, Andrew Morton wrote:
> On Mon, 19 Oct 2026 13:19:45 +0100 "Lorenzo Stoakes (ARM)" <ljs@xxxxxxxxxx> wrote:
>
> > On Mon, Oct 19, 2026 at 10:53:27AM +0100, Pedro Falcato wrote:
> > > On Fri, Oct 16, 2026 at 12:34:33PM +0100, Lorenzo Stoakes (ARM) wrote:
> >
> > > > So I think it's fine to just send it (early :) in the merge window.
> > > > ---
> > > > v2:
> > > > * Updated comment in vma_seqcount_is_write_locked() to mention the VMA
> > > >   being attached.
> > > > * Renamed reset_vma_seqcounts() to __mm_reset_vma_seqcounts().
> > > > * Used acquire semantics in vma_start_reads() to avoid race with reset -
> > > >   there is another acquire immediately after this one so it should just be
> > > >   noise perf-wise.
> > > > * Removed stable tag, will do the backports manually (just make the value
> > > >   64 bits...)
> > >
> > > I guess you're fitting this where __vm_anon_pgoff_lo now sits? If so, then
> > > this patch probably wants backporting to 7.3.
> >
> > Ack.
>
> I added cc:stable to the mm.git copy of this.

But that'll trigger the bots for every revision right? I don't want that, even
if they fail, that'll set off Sasha's bot who might get things spectacularly
wrong.

Could you update it to:

Cc: <stable@xxxxxxxxxxxxxxx> # v7.3.x

To be super clear about it.

Thanks!

--
Cheers, Lorenzo