linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shivank Garg <shivankg@amd.com>
To: Gregory Price <gourry@gourry.net>
Cc: seanjc@google.com, david@redhat.com, vbabka@suse.cz,
	willy@infradead.org, akpm@linux-foundation.org, shuah@kernel.org,
	pbonzini@redhat.com, brauner@kernel.org, viro@zeniv.linux.org.uk,
	ackerleytng@google.com, paul@paul-moore.com, jmorris@namei.org,
	serge@hallyn.com, pvorel@suse.cz, bfoster@redhat.com,
	tabba@google.com, vannapurve@google.com, chao.gao@intel.com,
	bharata@amd.com, nikunj@amd.com, michael.day@amd.com,
	yan.y.zhao@intel.com, Neeraj.Upadhyay@amd.com,
	thomas.lendacky@amd.com, michael.roth@amd.com, aik@amd.com,
	jgg@nvidia.com, kalyazin@amazon.com, peterx@redhat.com,
	jack@suse.cz, rppt@kernel.org, hch@infradead.org,
	cgzones@googlemail.com, ira.weiny@intel.com, rientjes@google.com,
	roypat@amazon.co.uk, ziy@nvidia.com, matthew.brost@intel.com,
	joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com,
	kent.overstreet@linux.dev, ying.huang@linux.alibaba.com,
	apopple@nvidia.com, chao.p.peng@intel.com, amit@infradead.org,
	ddutile@redhat.com, dan.j.williams@intel.com,
	ashish.kalra@amd.com, gshan@redhat.com, jgowans@amazon.com,
	pankaj.gupta@amd.com, papaluri@amd.com, yuzhao@google.com,
	suzuki.poulose@arm.com, quic_eberman@quicinc.com,
	aneeshkumar.kizhakeveetil@arm.com, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, kvm@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-coco@lists.linux.dev
Subject: Re: [RFC PATCH v8 4/7] mm/mempolicy: Export memory policy symbols
Date: Thu, 19 Jun 2025 16:43:00 +0530	[thread overview]
Message-ID: <4267108c-ac26-4528-97cc-0d160568baee@amd.com> (raw)
In-Reply-To: <aFLXRtCDfoNzQym6@gourry-fedora-PF4VCD3F>



On 6/18/2025 8:42 PM, Gregory Price wrote:
> On Wed, Jun 18, 2025 at 11:29:32AM +0000, Shivank Garg wrote:
>> KVM guest_memfd wants to implement support for NUMA policies just like
>> shmem already does using the shared policy infrastructure. As
>> guest_memfd currently resides in KVM module code, we have to export the
>> relevant symbols.
>>
>> In the future, guest_memfd might be moved to core-mm, at which point the
>> symbols no longer would have to be exported. When/if that happens is
>> still unclear.
>>
>> Acked-by: David Hildenbrand <david@redhat.com>
>> Acked-by: Vlastimil Babka <vbabka@suse.cz>
>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>> ---
>>  mm/mempolicy.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>> index 3b1dfd08338b..d98243cdf090 100644
>> --- a/mm/mempolicy.c
>> +++ b/mm/mempolicy.c
>> @@ -354,6 +354,7 @@ struct mempolicy *get_task_policy(struct task_struct *p)
>>  
>>  	return &default_policy;
>>  }
>> +EXPORT_SYMBOL_GPL(get_task_policy);
>>  
>>  static const struct mempolicy_operations {
>>  	int (*create)(struct mempolicy *pol, const nodemask_t *nodes);
>> @@ -487,6 +488,7 @@ void __mpol_put(struct mempolicy *pol)
>>  		return;
>>  	kmem_cache_free(policy_cache, pol);
>>  }
>> +EXPORT_SYMBOL_GPL(__mpol_put);
>>  
> 
> I'm concerned that get_task_policy doesn't actually increment the policy
> refcount - and mpol_cond_put only decrements the refcount for shared
> policies (vma policies) - while __mpol_put decrements it unconditionally.
> 
> If you look at how get_task_policy is used internally to mempolicy,
> you'll find that it either completes the operation in the context of the
> task lock (allocation time) or it calls mpol_get afterwards.

I agree. But the semantics of my usage isn't new. shmem use this in same way.

I think the alloc_frozen_pages_noprof(), alloc_pages_bulk_mempolicy_noprof()
calls get_task_policy without task_lock or calling mpol_get.

> 
> Exporting this as-is creates a triping hazard, if only because get/put
> naming implies reference counting.

Since KVM is the only user, we could consider newly added EXPORT_SYMBOL_GPL_FOR_MODULES(..., "kvm")
to avoid wider exposure.
Does this solve your concern?
Or should we rename these functions.
What should be the preferred approach?

Thanks,
Shivank


  reply	other threads:[~2025-06-19 11:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18 11:29 [RFC PATCH v8 0/7] Add NUMA mempolicy support for KVM guest-memfd Shivank Garg
2025-06-18 11:29 ` [RFC PATCH v8 1/7] security: Export anon_inode_make_secure_inode for KVM guest_memfd Shivank Garg
2025-06-18 11:29 ` [RFC PATCH v8 2/7] KVM: guest_memfd: Use guest mem inodes instead of anonymous inodes Shivank Garg
2025-06-18 11:29 ` [RFC PATCH v8 3/7] mm/filemap: Add mempolicy support to the filemap layer Shivank Garg
2025-06-19 15:08   ` Vlastimil Babka
2025-06-19 16:03   ` Matthew Wilcox
2025-06-20  5:59     ` Shivank Garg
2025-06-20  9:37       ` Vlastimil Babka
2025-06-20 14:34       ` Matthew Wilcox
2025-06-20 14:52         ` Shivank Garg
2025-06-20 14:58           ` Matthew Wilcox
2025-06-20 14:34   ` [PATCH 1/2] filemap: Add a mempolicy argument to filemap_alloc_folio() Matthew Wilcox (Oracle)
2025-06-23  6:13     ` Gupta, Pankaj
2025-06-23  7:19     ` Vlastimil Babka
2025-06-20 14:34   ` [PATCH 2/2] filemap: Add __filemap_get_folio_mpol() Matthew Wilcox (Oracle)
2025-06-20 16:53     ` Matthew Wilcox
2025-06-22 18:43       ` Andrew Morton
2025-06-22 19:02         ` Shivank Garg
2025-06-22 22:16           ` Andrew Morton
2025-06-23  4:18             ` Shivank Garg
2025-06-23 10:01             ` Shivank Garg
2025-06-23  7:16           ` Vlastimil Babka
2025-06-23  9:56             ` Shivank Garg
2025-06-23  6:15     ` Gupta, Pankaj
2025-06-23  7:20     ` Vlastimil Babka
2025-06-18 11:29 ` [RFC PATCH v8 4/7] mm/mempolicy: Export memory policy symbols Shivank Garg
2025-06-18 15:12   ` Gregory Price
2025-06-19 11:13     ` Shivank Garg [this message]
2025-06-19 16:28       ` Vlastimil Babka
2025-06-18 11:29 ` [RFC PATCH v8 5/7] KVM: guest_memfd: Add slab-allocated inode cache Shivank Garg
2025-06-24  4:16   ` Huang, Ying
2025-06-29 18:25     ` Shivank Garg
2025-06-18 11:29 ` [RFC PATCH v8 6/7] KVM: guest_memfd: Enforce NUMA mempolicy using shared policy Shivank Garg
2025-06-18 11:29 ` [RFC PATCH v8 7/7] KVM: guest_memfd: selftests: Add tests for mmap and NUMA policy support Shivank Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4267108c-ac26-4528-97cc-0d160568baee@amd.com \
    --to=shivankg@amd.com \
    --cc=Neeraj.Upadhyay@amd.com \
    --cc=ackerleytng@google.com \
    --cc=aik@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=amit@infradead.org \
    --cc=aneeshkumar.kizhakeveetil@arm.com \
    --cc=apopple@nvidia.com \
    --cc=ashish.kalra@amd.com \
    --cc=bfoster@redhat.com \
    --cc=bharata@amd.com \
    --cc=brauner@kernel.org \
    --cc=byungchul@sk.com \
    --cc=cgzones@googlemail.com \
    --cc=chao.gao@intel.com \
    --cc=chao.p.peng@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=gourry@gourry.net \
    --cc=gshan@redhat.com \
    --cc=hch@infradead.org \
    --cc=ira.weiny@intel.com \
    --cc=jack@suse.cz \
    --cc=jgg@nvidia.com \
    --cc=jgowans@amazon.com \
    --cc=jmorris@namei.org \
    --cc=joshua.hahnjy@gmail.com \
    --cc=kalyazin@amazon.com \
    --cc=kent.overstreet@linux.dev \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=michael.day@amd.com \
    --cc=michael.roth@amd.com \
    --cc=nikunj@amd.com \
    --cc=pankaj.gupta@amd.com \
    --cc=papaluri@amd.com \
    --cc=paul@paul-moore.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pvorel@suse.cz \
    --cc=quic_eberman@quicinc.com \
    --cc=rakie.kim@sk.com \
    --cc=rientjes@google.com \
    --cc=roypat@amazon.co.uk \
    --cc=rppt@kernel.org \
    --cc=seanjc@google.com \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vannapurve@google.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=yan.y.zhao@intel.com \
    --cc=ying.huang@linux.alibaba.com \
    --cc=yuzhao@google.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox