linux-kernel - Re: [PATCH] /proc/pid/smaps: add mo info for vma in NOMMU system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c08c2f5f-2607-42d3-8d68-4ea99c2d7e72@redhat.com>
Date: Tue, 10 Jun 2025 13:15:23 +0200
From: David Hildenbrand <david@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
 wangfushuai <wangfushuai@...du.com>
Cc: andrii@...nel.org, osalvador@...e.de, Liam.Howlett@...cle.com,
 christophe.leroy@...roup.eu, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] /proc/pid/smaps: add mo info for vma in NOMMU system

On 07.06.25 23:18, Andrew Morton wrote:
> On Sun, 8 Jun 2025 00:53:35 +0800 wangfushuai <wangfushuai@...du.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