[PATCH RESEND 0/3] mm: trace: decode architecture-specific VMA flags

[PATCH RESEND 0/3] mm: trace: decode architecture-specific VMA flags

[Meijing Zhao]

From: Meijing Zhao <zhaomeijing@lixiang.com>

show_vma_flags(), which is used by VMA tracepoints and %pGv, names
generic VM_* bits but does not fully decode architecture-specific flag
positions.  As a result, trace output and VMA dumps can show a generic
"arch_1" name or a raw hexadecimal value instead of the meaning assigned
by the target architecture.

This series adds symbolic names for the arm64 and sparc64 meanings of
VM_ARCH_1, arm64 MTE flags, user shadow stack flags, and protection-key
encoding bits under their corresponding configuration guards.

The original submission was rewritten by the mail gateway as a
multipart HTML message and had a disclaimer appended, causing the vger
mailing lists to reject it.  This resend uses a mail transport that
preserves plain-text messages.  There are no code changes.

Meijing Zhao (3):
  mm: trace: decode arm64 and sparc64 VM_ARCH_1 flags
  mm: trace: decode MTE and shadow stack VMA flags
  mm: trace: name protection key encoding bits

 include/trace/events/mmflags.h | 43 ++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

-- 
2.25.1

[PATCH RESEND 1/3] mm: trace: decode arm64 and sparc64 VM_ARCH_1 flags

[Meijing Zhao]

From: Meijing Zhao <zhaomeijing@lixiang.com>

The VM_ARCH_1 bit has architecture-specific meanings.  show_vma_flags(),
which is used by VMA tracepoints and %pGv, already reports the powerpc,
parisc and no-MMU meanings, but falls back to the generic "arch_1" name
on arm64 and sparc64.

Report VM_ARM64_BTI as "bti" and VM_SPARC_ADI as "adi" so trace output
and %pGv dumps expose the actual architecture-specific state.  These
names also match the mnemonics used by /proc/<pid>/smaps.

Signed-off-by: Meijing Zhao <zhaomeijing@lixiang.com>
---
 include/trace/events/mmflags.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
index a6e5a44c9b42..add5ad6843e8 100644
--- a/include/trace/events/mmflags.h
+++ b/include/trace/events/mmflags.h
@@ -176,6 +176,10 @@ IF_HAVE_PG_ARCH_3(arch_3)
 #define __VM_ARCH_SPECIFIC_1 {VM_SAO,     "sao"           }
 #elif defined(CONFIG_PARISC)
 #define __VM_ARCH_SPECIFIC_1 {VM_GROWSUP,	"growsup"	}
+#elif defined(CONFIG_SPARC64)
+#define __VM_ARCH_SPECIFIC_1 {VM_SPARC_ADI, "adi"		}
+#elif defined(CONFIG_ARM64)
+#define __VM_ARCH_SPECIFIC_1 {VM_ARM64_BTI, "bti"		}
 #elif !defined(CONFIG_MMU)
 #define __VM_ARCH_SPECIFIC_1 {VM_MAPPED_COPY,"mappedcopy"	}
 #else
-- 
2.25.1

[PATCH RESEND 2/3] mm: trace: decode MTE and shadow stack VMA flags

[Meijing Zhao]

From: Meijing Zhao <zhaomeijing@lixiang.com>

show_vma_flags(), which is used by VMA tracepoints and %pGv, leaves
architecture-specific HIGH_ARCH_* bits unnamed.  Arm64 MTE flags and
user shadow stack flags are therefore printed as raw hexadecimal values.

These bit positions are shared between architectures.  For example, bit
37 represents VM_MTE_ALLOWED on arm64 but VM_SHADOW_STACK on x86, so a
shared HIGH_ARCH_* bit cannot be given an unconditional name.

Add conditionally compiled names for VM_MTE, VM_MTE_ALLOWED and
VM_SHADOW_STACK.  Keep the configuration guards aligned with the
definitions of these aliases so each shared bit position is decoded
according to the target architecture.

For example, an arm64 VMA containing VM_MTE_ALLOWED is now printed as:

  ...|account|mte_allowed|...

instead of:

  ...|account|0x2000000000

Signed-off-by: Meijing Zhao <zhaomeijing@lixiang.com>
---
 include/trace/events/mmflags.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
index add5ad6843e8..2d76daacb70c 100644
--- a/include/trace/events/mmflags.h
+++ b/include/trace/events/mmflags.h
@@ -204,6 +204,19 @@ IF_HAVE_PG_ARCH_3(arch_3)
 # define IF_HAVE_VM_DROPPABLE(flag, name)
 #endif
 
+#ifdef CONFIG_ARM64_MTE
+# define IF_HAVE_VM_MTE(flag, name) {flag, name},
+#else
+# define IF_HAVE_VM_MTE(flag, name)
+#endif
+
+#if defined(CONFIG_X86_USER_SHADOW_STACK) || defined(CONFIG_RISCV_USER_CFI) || \
+	defined(CONFIG_ARM64_GCS)
+# define IF_HAVE_VM_SHADOW_STACK(flag, name) {flag, name},
+#else
+# define IF_HAVE_VM_SHADOW_STACK(flag, name)
+#endif
+
 #define __def_vmaflag_names						\
 	{VM_READ,			"read"		},		\
 	{VM_WRITE,			"write"		},		\
@@ -238,6 +251,9 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY,	"softdirty"	)		\
 	{VM_HUGEPAGE,			"hugepage"	},		\
 	{VM_NOHUGEPAGE,			"nohugepage"	},		\
 IF_HAVE_VM_DROPPABLE(VM_DROPPABLE,	"droppable"	)		\
+IF_HAVE_VM_MTE(VM_MTE,			"mte")			\
+IF_HAVE_VM_MTE(VM_MTE_ALLOWED,		"mte_allowed")		\
+IF_HAVE_VM_SHADOW_STACK(VM_SHADOW_STACK, "shadow_stack")	\
 	{VM_MERGEABLE,			"mergeable"	}		\
 
 #define show_vma_flags(flags)						\
-- 
2.25.1

[PATCH RESEND 3/3] mm: trace: name protection key encoding bits

[Meijing Zhao]

From: Meijing Zhao <zhaomeijing@lixiang.com>

Protection keys are encoded in architecture-specific HIGH_ARCH_* VMA
flag bits.  show_vma_flags(), which is used by VMA tracepoints and %pGv,
does not name those bits, leaving them as raw hexadecimal values.

Name the protection-key encoding bits pkey_bit0 through pkey_bit4 under
CONFIG_ARCH_HAS_PKEYS.  The names make clear that these are bits of one
protection-key value rather than independent protection keys.  For
example, protection key 3 is represented as:

  pkey_bit0|pkey_bit1

Honor CONFIG_ARCH_PKEY_BITS when exposing bit 3 and bit 4 so only bits
provided by the architecture are included.

Signed-off-by: Meijing Zhao <zhaomeijing@lixiang.com>
---
 include/trace/events/mmflags.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
index 2d76daacb70c..c8b8a980f8c7 100644
--- a/include/trace/events/mmflags.h
+++ b/include/trace/events/mmflags.h
@@ -204,6 +204,24 @@ IF_HAVE_PG_ARCH_3(arch_3)
 # define IF_HAVE_VM_DROPPABLE(flag, name)
 #endif
 
+#ifdef CONFIG_ARCH_HAS_PKEYS
+# define IF_HAVE_VM_PKEY(flag, name) {flag, name},
+#if CONFIG_ARCH_PKEY_BITS > 3
+# define IF_HAVE_VM_PKEY3(flag, name) {flag, name},
+#else
+# define IF_HAVE_VM_PKEY3(flag, name)
+#endif
+#if CONFIG_ARCH_PKEY_BITS > 4
+# define IF_HAVE_VM_PKEY4(flag, name) {flag, name},
+#else
+# define IF_HAVE_VM_PKEY4(flag, name)
+#endif
+#else
+# define IF_HAVE_VM_PKEY(flag, name)
+# define IF_HAVE_VM_PKEY3(flag, name)
+# define IF_HAVE_VM_PKEY4(flag, name)
+#endif
+
 #ifdef CONFIG_ARM64_MTE
 # define IF_HAVE_VM_MTE(flag, name) {flag, name},
 #else
@@ -251,6 +269,11 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY,	"softdirty"	)		\
 	{VM_HUGEPAGE,			"hugepage"	},		\
 	{VM_NOHUGEPAGE,			"nohugepage"	},		\
 IF_HAVE_VM_DROPPABLE(VM_DROPPABLE,	"droppable"	)		\
+IF_HAVE_VM_PKEY(VM_PKEY_BIT0,		"pkey_bit0")		\
+IF_HAVE_VM_PKEY(VM_PKEY_BIT1,		"pkey_bit1")		\
+IF_HAVE_VM_PKEY(VM_PKEY_BIT2,		"pkey_bit2")		\
+IF_HAVE_VM_PKEY3(VM_PKEY_BIT3,		"pkey_bit3")		\
+IF_HAVE_VM_PKEY4(VM_PKEY_BIT4,		"pkey_bit4")		\
 IF_HAVE_VM_MTE(VM_MTE,			"mte")			\
 IF_HAVE_VM_MTE(VM_MTE_ALLOWED,		"mte_allowed")		\
 IF_HAVE_VM_SHADOW_STACK(VM_SHADOW_STACK, "shadow_stack")	\
-- 
2.25.1

Re: [PATCH RESEND 0/3] mm: trace: decode architecture-specific VMA flags

[Meijing Zhao]

Hi,

A gentle ping on this patch series. It has been about two weeks since
it was posted, and I have not received any feedback yet.

Would you have a chance to take a look? Please let me know if I should
rebase or resend the series.

For reference, the original thread is available here:
https://lore.kernel.org/linux-mm/20260723092905.761037-1-zhaomeijing100@gmail.com/

Thanks,
Meijing Zhao

Re: [PATCH RESEND 0/3] mm: trace: decode architecture-specific VMA flags

[Steven Rostedt]

On Fri,  7 Aug 2026 11:13:49 +0800
Meijing Zhao <zhaomeijing100@gmail.com> wrote:

> Hi,
> 
> A gentle ping on this patch series. It has been about two weeks since
> it was posted, and I have not received any feedback yet.
> 
> Would you have a chance to take a look? Please let me know if I should
> rebase or resend the series.
> 
> For reference, the original thread is available here:
> https://lore.kernel.org/linux-mm/20260723092905.761037-1-zhaomeijing100@gmail.com/
> 

You may need to Cc the MM maintainers too. Not just linux-mm mailing list.
Modifications of tracepoints in subsystems belong to the subsystem
maintainer, not the tracing maintainers. We just maintain the
infrastructure, not the content.

-- Steve

Re: [PATCH RESEND 0/3] mm: trace: decode architecture-specific VMA flags

[Andrew Morton]

On Fri, 7 Aug 2026 08:47:45 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri,  7 Aug 2026 11:13:49 +0800
> Meijing Zhao <zhaomeijing100@gmail.com> wrote:
> 
> > Hi,
> > 
> > A gentle ping on this patch series. It has been about two weeks since
> > it was posted, and I have not received any feedback yet.
> > 
> > Would you have a chance to take a look? Please let me know if I should
> > rebase or resend the series.
> > 
> > For reference, the original thread is available here:
> > https://lore.kernel.org/linux-mm/20260723092905.761037-1-zhaomeijing100@gmail.com/
> > 
> 
> You may need to Cc the MM maintainers too. Not just linux-mm mailing list.
> Modifications of tracepoints in subsystems belong to the subsystem
> maintainer, not the tracing maintainers. We just maintain the
> infrastructure, not the content.

get_maintainer isn't very useful with include/trace/events/mmflags.h.

As it's a vma-flags thing then cc'ing Lorenzo Stoakes (ARM)
<ljs@kernel.org> would be appropriate.

We're in lockdown-for-merge-window mode so please plan on a resend
after 7.3-rc1.

AI review made a minor comment regarding the changelog:
	https://sashiko.dev/#/patchset/20260723092905.761037-1-zhaomeijing100@gmail.com

Re: [PATCH RESEND 0/3] mm: trace: decode architecture-specific VMA flags

[Steven Rostedt]

On Fri, 7 Aug 2026 12:50:54 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> get_maintainer isn't very useful with include/trace/events/mmflags.h.

Someone (probably me) needs to go through and add each of the files in
include/trace/events/* to their proper owner in the MAINTAINERS file :-p

-- Steve