linux-kernel - Re: [PATCH] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <osc3liyap3yp4zbnuxam7o53tcy47pinpl6pw6fmi5ch7cltp5@w32eddzvpjsk>
Date: Thu, 18 Dec 2025 20:25:33 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: akpm@...ux-foundation.org, gregkh@...uxfoundation.org, 
	david@...nel.org, brauner@...nel.org, mingo@...nel.org, sean@...e.io, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs/proc: Expose mm_cpumask in /proc/[pid]/status

On Wed, Dec 17, 2025 at 06:33:26PM +0100, Oleg Nesterov wrote:
> Can't really comment this patch... I mean the intent.
> Just a couple of nits:

Hi Oleg,

Long time no speak. Thank you for your response.

> 	- I think this patch should also update
> 	Documentation/filesystems/proc.rst

Acknowledged. I will do so in the follow-up patch.

> 	- I won't object, but do we really need/want another "if (mm)" block ?

I appreciate your observation; technically, the code could be more compact
by merging this into the earlier conditional block. However, my reasoning
here was primarily a personal preference regarding the resulting output of
/proc/[PID]/status. I felt it was beneficial to keep "Cpus_active_mm" and
"Cpus_active_mm_list" in close proximity to their counterparts,
"Cpus_allowed" and "Cpus_allowed_list", to provide a more intuitive and
logically grouped view for the user.

> 	- I guess this is just my poor English, but the usage of "affinity"
> 	  in the changelog/comment looks a bit confusing to me ;) As if this
> 	  refers to task_struct.cpus_mask.
> 
> 	  Fortunately "Cpus_active_mm..." in task_cpus_active_mm() makes it
> 	  more clear, so feel free to ignore.

I appreciate your perspective on the use of the word "affinity."
My intention was to describe the relationship between CPUs where a memory
descriptor is "active" and the CPUs where the thread is allowed to execute.
In other words: the affinity set the boundary; the mm_cpumask recorded the
arrival. However, I see how this could be misconstrued. I will certainly
refine the language in the changelog and ensure there is no ambiguity
between the two.

Kind regards,
-- 
Aaron Tomlin

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