linux-kernel - Re: [v2 PATCH 1/1] fs/proc: Expose mm

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 for Android: free password hash cracker in your pocket

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

Message-ID: <3cbg222hwqejusthscnapmy5s4p3vztyaz6yeg2xz7qxdn5p7c@rcvchlw427ta>
Date: Thu, 15 Jan 2026 13:40:51 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: oleg@...hat.com, akpm@...ux-foundation.org, gregkh@...uxfoundation.org, 
	brauner@...nel.org, mingo@...nel.org, neelx@...e.com, sean@...e.io, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [v2 PATCH 1/1] fs/proc: Expose mm_cpumask in /proc/[pid]/status

On Tue, Jan 06, 2026 at 07:54:54PM +0100, David Hildenbrand (Red Hat) wrote:
> Yes, starting with a very restrictive set, and carefully documenting it
> sounds good to me.

Hi David,

Acknowledged.

> One question is what would happen if these semantics one day change on x86.
> I guess best we can do is to ... document it very carefully.

Indeed.

> > I can document this arch-specific limitation in
> > Documentation/filesystems/proc.rst and wrapped the implementation in
> > CONFIG_X86 to avoid exposing "Best Effort" or zeroed-out data on
> > architectures where the mask is not meaningful.
> > 
> > Please let me know your thoughts.
> 
> Something along these lines. Maybe we want an CONFIG_ARCH_* define to unlock
> this from arch code.

That is a wonderful idea. I'll incorporate this suggestion within the next
iteration.


Kind regards,
-- 
Aaron Tomlin

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)