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.
Exporting this as-is creates a triping hazard, if only because get/put naming implies reference counting.
~Gregory