linux-kernel - Re: [RFC PATCH 1/4] mm/mempolicy: Expose policy

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: <aFBXuTtwhAV7BHeY@gourry-fedora-PF4VCD3F>
Date: Mon, 16 Jun 2025 12:43:21 -0500
From: Gregory Price <gourry@...rry.net>
To: Bijan Tabatabai <bijan311@...il.com>
Cc: David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	sj@...nel.org, akpm@...ux-foundation.org, corbet@....net,
	ziy@...dia.com, matthew.brost@...el.com, joshua.hahnjy@...il.com,
	rakie.kim@...com, byungchul@...com, ying.huang@...ux.alibaba.com,
	apopple@...dia.com, bijantabatab@...ron.com,
	venkataravis@...ron.com, emirakhur@...ron.com, ajayjoshi@...ron.com,
	vtavarespetr@...ron.com, damon@...ts.linux.dev
Subject: Re: [RFC PATCH 1/4] mm/mempolicy: Expose policy_nodemask() in
 include/linux/mempolicy.h

On Mon, Jun 16, 2025 at 09:16:55AM -0500, Bijan Tabatabai wrote:
> >
> > Which, you also have during the rmap walk.
> 
> There is another subtle dependency in get_vma_policy.
> It first checks if a VMA policy exists, and if it doesn't, it uses the
> task policy of the current task, which doesn't make sense when called
> by a kdamond thread.
> 
> However, I don't think this will change what seems to be our consensus
> of adding a new helper function.
> 

Hate to interject here, but this gets worse the further you dig in.  The
mempolicy interface as a whole has many, many, many hidden references to
current->mempolicy and current->mems_allowed.  External interface
references to a task or vma mempolicy is a problem i explored somewhat
extensively when I prototyped `set_mempolicy2()`. It did not go well.

Generally, mempolicy is not well structured to allow external actors on
a task's mempolicy.  Accessing a task's mempolicy requires operating in
a task's context or at least taking a reference on that task's mempolicy
(which requires taking the task_struct lock).

I will just say that mempolicy is *extremely* current-task centric - and
very much allocation-time centric (i.e. the internal workings don't
really want to consider migration all that much).  You'll probably find
that this project requires rethinking mempolicy's external interfaces in
general (which is sorely needed anyway).

I think this path to modifying mempolicy to support DAMON is a bit
ambitious for where mempolicy is at the moment. You may be better off
duplicating the interleave-weight logic and making some helper functions
to get the weight data, and then coming back around to generalize it
later.

~Gregory