Add mo in /proc/[pid]/smaps to indicate vma is marked VM_MAYOVERLAY,
which means the file mapping may overlay in NOMMU system.

Fixes: b6b7a8faf05c ("mm/nommu: don't use VM_MAYSHARE for MAP_PRIVATE mappings")
Signed-off-by: wangfushuai <wangfushuai@baidu.com>
---
 Documentation/filesystems/proc.rst | 1 +
 fs/proc/task_mmu.c                 | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 2a17865dfe39..d280594656a3 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -609,6 +609,7 @@ encoded manner. The codes are the following:
     uw    userfaultfd wr-protect tracking
     ss    shadow/guarded control stack page
     sl    sealed
+    mo    may overlay file mapping
     ==    =======================================
 
 Note that there is no guarantee that every flag and associated mnemonic will
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 27972c0749e7..ad08807847de 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -970,7 +970,11 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
 		[ilog2(VM_HUGEPAGE)]	= "hg",
 		[ilog2(VM_NOHUGEPAGE)]	= "nh",
 		[ilog2(VM_MERGEABLE)]	= "mg",
+#ifdef CONFIG_MMU
 		[ilog2(VM_UFFD_MISSING)]= "um",
+#else
+		[ilog2(VM_MAYOVERLAY)]	= "mo",
+#endif
 		[ilog2(VM_UFFD_WP)]	= "uw",
 #ifdef CONFIG_ARM64_MTE
 		[ilog2(VM_MTE)]		= "mt",
-- 
2.36.1

On Sun, 8 Jun 2025 00:53:35 +0800 wangfushuai <wangfushuai@baidu.com> wrote:

> Add mo in /proc/[pid]/smaps to indicate vma is marked VM_MAYOVERLAY,
> which means the file mapping may overlay in NOMMU system.
>
> ...
>
> Fixes: b6b7a8faf05c ("mm/nommu: don't use VM_MAYSHARE for MAP_PRIVATE mappings")

In what sense does this "fix" b6b7a8faf05c?  Which, after all, said "no
functional change intended".

It does appear to be an improvement to the NOMMU user interface. 
However it is non-backward-compatible - perhaps there's existing
userspace which is looking for "um" and which now needs to be changed
to look for "mo".

We could prevent this by continiing to show "um" on CONFIG_MMU and
additionally showing the new "mo".  If we do this, let's have a code
comment in show_smap_vma_flags() explaining why the code is this way.

On 07.06.25 23:18, Andrew Morton wrote:
> On Sun, 8 Jun 2025 00:53:35 +0800 wangfushuai <wangfushuai@baidu.com> wrote:
> 
>> Add mo in /proc/[pid]/smaps to indicate vma is marked VM_MAYOVERLAY,
>> which means the file mapping may overlay in NOMMU system.
>>
>> ...
>>
>> Fixes: b6b7a8faf05c ("mm/nommu: don't use VM_MAYSHARE for MAP_PRIVATE mappings")
> 
> In what sense does this "fix" b6b7a8faf05c?  Which, after all, said "no
> functional change intended".
> 
> It does appear to be an improvement to the NOMMU user interface.
> However it is non-backward-compatible - perhaps there's existing
> userspace which is looking for "um" and which now needs to be changed
> to look for "mo".

Very likely no. Nobody should be caring about this kernel-internal thing.

But let's read the doc:

"Note that there is no guarantee that every flag and associated mnemonic 
will be present in all further kernel releases. Things get changed, the 
flags may be vanished or the reverse -- new added. Interpretation of 
their meaning might change in future as well. So each consumer of these 
flags has to follow each specific kernel version for the exact semantic."

So nobody should be relying on any of that, but the doc goes on

"
This file is only present if the CONFIG_MMU kernel configuration option 
is enabled.
"

Huh?

$ grep "task_mmu" fs/proc/Makefile
CFLAGS_task_mmu.o       += -Wno-override-init
proc-$(CONFIG_MMU)      := task_mmu.o

NAK

-- 
Cheers,

David / dhildenb

On 07.06.25 18:53, wangfushuai wrote:
> Add mo in /proc/[pid]/smaps to indicate vma is marked VM_MAYOVERLAY,
> which means the file mapping may overlay in NOMMU system.
> 
> Fixes: b6b7a8faf05c ("mm/nommu: don't use VM_MAYSHARE for MAP_PRIVATE mappings")
> Signed-off-by: wangfushuai <wangfushuai@baidu.com>
> ---
>   Documentation/filesystems/proc.rst | 1 +
>   fs/proc/task_mmu.c                 | 4 ++++
>   2 files changed, 5 insertions(+)
> 
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index 2a17865dfe39..d280594656a3 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -609,6 +609,7 @@ encoded manner. The codes are the following:
>       uw    userfaultfd wr-protect tracking
>       ss    shadow/guarded control stack page
>       sl    sealed
> +    mo    may overlay file mapping
>       ==    =======================================
>   
>   Note that there is no guarantee that every flag and associated mnemonic will
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 27972c0749e7..ad08807847de 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -970,7 +970,11 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
>   		[ilog2(VM_HUGEPAGE)]	= "hg",
>   		[ilog2(VM_NOHUGEPAGE)]	= "nh",
>   		[ilog2(VM_MERGEABLE)]	= "mg",
> +#ifdef CONFIG_MMU
>   		[ilog2(VM_UFFD_MISSING)]= "um",
> +#else
> +		[ilog2(VM_MAYOVERLAY)]	= "mo",
> +#endif
>   		[ilog2(VM_UFFD_WP)]	= "uw",
>   #ifdef CONFIG_ARM64_MTE
>   		[ilog2(VM_MTE)]		= "mt",

That is mostly an internal-only flag. Why would we want to expose that 
to user space?

-- 
Cheers,

David / dhildenb