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

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

[Miguel Ojeda]

On Fri, 13 Nov 2026 10:52:47 -0500 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> @@ -589,6 +593,16 @@ static inline void vma_end_write_all(struct mm_struct *mm)
>  {
>  	mmap_assert_write_locked(mm);
>  	mm_lock_seqcount_end(mm);
> +
> +	/*
> +	 * VMA seqcounts are not updated on unlock, so once the mm seqcount has
> +	 * wrapped, any VMA still carrying a sequence number from before the
> +	 * wrap would satisfy __is_vma_write_locked() when that number comes
> +	 * round again, and readers would not be excluded. Reset every VMA's
> +	 * seqcount so that no stale value survives the wrap.
> +	 */
> +	if (unlikely(!mm->mm_lock_seq.sequence))
> +		__mm_reset_vma_seqcounts(mm);
>  }

In a UM ~defconfig build with LLVM:

    In file included from arch/um/kernel/asm-offsets.c:8:
    In file included from ./include/linux/audit.h:13:
    In file included from ./include/linux/ptrace.h:10:
    In file included from ./include/linux/pid_namespace.h:7:
    In file included from ./include/linux/mm.h:18:
    ./include/linux/mmap_lock.h:604:20: error: no member named 'mm_lock_seq' in 'struct mm_struct'
      604 |         if (unlikely(!mm->mm_lock_seq.sequence))
          |                       ~~  ^
    ./include/linux/compiler.h:77:42: note: expanded from macro 'unlikely'
       77 | # define unlikely(x)    __builtin_expect(!!(x), 0)
          |

That exists only under `CONFIG_PER_VMA_LOCK` (commit 47e725702b0b ("mm:
make per-VMA locks available universally") from Dave's series was not
backported).

I hope this helps!

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: linux-mm@kvack.org

Cc: Jose A. Perez de Azpillaga <azpijr@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>

Cheers,
Miguel

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

[SJ Park]

On Sat, 14 Nov 2026 01:39:12 +0100 Miguel Ojeda <ojeda@kernel.org> wrote:

> On Fri, 13 Nov 2026 10:52:47 -0500 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > @@ -589,6 +593,16 @@ static inline void vma_end_write_all(struct mm_struct *mm)
> >  {
> >  	mmap_assert_write_locked(mm);
> >  	mm_lock_seqcount_end(mm);
> > +
> > +	/*
> > +	 * VMA seqcounts are not updated on unlock, so once the mm seqcount has
> > +	 * wrapped, any VMA still carrying a sequence number from before the
> > +	 * wrap would satisfy __is_vma_write_locked() when that number comes
> > +	 * round again, and readers would not be excluded. Reset every VMA's
> > +	 * seqcount so that no stale value survives the wrap.
> > +	 */
> > +	if (unlikely(!mm->mm_lock_seq.sequence))
> > +		__mm_reset_vma_seqcounts(mm);
> >  }
> 
> In a UM ~defconfig build with LLVM:
> 
>     In file included from arch/um/kernel/asm-offsets.c:8:
>     In file included from ./include/linux/audit.h:13:
>     In file included from ./include/linux/ptrace.h:10:
>     In file included from ./include/linux/pid_namespace.h:7:
>     In file included from ./include/linux/mm.h:18:
>     ./include/linux/mmap_lock.h:604:20: error: no member named 'mm_lock_seq' in 'struct mm_struct'
>       604 |         if (unlikely(!mm->mm_lock_seq.sequence))
>           |                       ~~  ^
>     ./include/linux/compiler.h:77:42: note: expanded from macro 'unlikely'
>        77 | # define unlikely(x)    __builtin_expect(!!(x), 0)
>           |
> 
> That exists only under `CONFIG_PER_VMA_LOCK` (commit 47e725702b0b ("mm:
> make per-VMA locks available universally") from Dave's series was not
> backported).

I found same thing while running kunit.  I also confirmed both applying commit
47e725702b0b from Dave and reverting this patch fix the problem on my setup.


Thanks,
SJ

[...]