Re: [PATCH 05/13] mm: prefer mm->def_vma_flags in mm logic

Lorenzo Stoakes <[email protected]> Thu, 2 Jul 2026 16:24:37 +0100
Newsgroups gmane.comp.freedesktop.xorg.drivers.intel,gmane.linux.ports.mips,gmane.linux.kernel,gmane.linux.ports.ppc64.devel,gmane.comp.video.dri.devel,gmane.linux.ports.arm.kernel,gmane.linux.kernel.samsung-soc,gmane.linux.ports.arm.msm,gmane.comp.freedesktop.xorg.drivers.freedreno,gmane.comp.freedesktop.xorg.nouveau,gmane.linux.ports.arm.rockchip,gmane.linux.ports.tegra,gmane.comp.emulators.xen.devel,gmane.linux.kernel.aio.general,gmane.linux.file-systems,gmane.linux.kernel.mm,gmane.linux.sound
Message-ID <akaCFf_SjccZznnP@lucifer> 
On Thu, Jul 02, 2026 at 08:10:22PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:28PM +0100, Lorenzo Stoakes wrote:
> >Currently mm->def_flags (of type vm_flags_t) is union'd with
> >mm->def_vma_flags (of type vma_flags_t).
> >
> >As part of the effort to convert vm_flags_t usage to vma_flags_t (in order
> >to no longer be arbitrarily limited to a system word size for VMA flags),
> >prefer mm->def_vma_flags to mm->def_flags throughout the mm logic.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <[email protected]>
> >---
> > mm/debug.c |  2 +-
> > mm/mlock.c | 13 +++++++------
> > mm/mmap.c  | 11 ++++++-----
> > mm/vma.c   |  4 ++--
> > 4 files changed, 16 insertions(+), 14 deletions(-)
> >
> >diff --git a/mm/debug.c b/mm/debug.c
> >index 497654b36f1a..f0a354a9496a 100644
> >--- a/mm/debug.c
> >+++ b/mm/debug.c
> >@@ -226,7 +226,7 @@ void dump_mm(const struct mm_struct *mm)
> > 		mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
> > #endif
> > 		atomic_read(&mm->tlb_flush_pending),
> >-		mm->def_flags, &mm->def_flags
> >+		vma_flags_to_legacy(mm->def_vma_flags), &mm->def_vma_flags
> > 	);
>
> While at it, one thing for later: dump_mm() still assumes one-world VMA
> flags. That works today since vma_flags_t is one word. Maybe worth a
> BUILD_BUG_ON() here, before that stops being true?

Ah yeah that could actually be pretty straightforward, if you see
https://www.kernel.org/doc/Documentation/printk-formats.txt there is a bitmap
format that could be used.

Can do that on a respin!

>
> Not a big deal though. Feel free to add:
>
> Reviewed-by: Lance Yang <[email protected]>
>
> > }
> > EXPORT_SYMBOL(dump_mm);
> [...]

Cheers, Lorenzo