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

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

On Wed, Oct 28, 2026 at 05:34:38PM -0700, Suren Baghdasaryan wrote:
> Sorry for missing this fix before (due to my vacation) and only now

Never apologise for taking a holiday ;)

> finding it. From a quick look it seems correct but I'll spend some
> more time reviewing and testing it.
> Thanks Lorenzo for the fix! I completely overlooked this overflow
> side-effect. And thanks to Liam for flagging it!

No worries, though it has already been merged -> Linus's tree (lol). Obviously
if you find anything of concern we can chase up!

The general idea is simple, really - though there's nuances with the memory
barriers (ugh).

First off, it turns out we don't have to use UINT_MAX when initialising a
VMA, since commit e5e7fb278e59 ("mm: convert mm_lock_seq to a proper
seqcount"), as 0 works just as well (it's not observed since VMA is
detached at that point).

Then we can simply detect when there's about to be an overflow, and zero
every VMA's write seqcount.

This is done without VMA write lock and with potential concurrent
readers. Which is fine, since the write locks are about to be unlocked
anyway, so any write-locked VMAs can either be encountered as write-locked
or not-write-locked safely.

0 is even, so that marks everything as unlocked. However, to avoid read
locks spuriously failing due to vma->vm_lock_seq == mm->mm_lock_seq, that
check is updated to also test whether the seqlock is odd (write-locked), if
not it allows a read-lock.

Since the 'reset' doesn't acquire VMA write lock (not required and not
really meaningful in the context), nor does it block read locks, it causes
no interruptions on that side.

And, as per the numbers I got the LLM to obtain that I shared with Pedro,
there's no meaningful latency when this happens, which for most workloads
takes ~days/weeks to achieve.

For backports, which lack my anon pgoff stuff, I will simply make the
fields 64-bit which make it practically impossible to hit the issue.

Let me know if you have any questions/concerns, thanks!

-- Cheers, Lorenzo