From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4707EC7115A for ; Wed, 18 Jun 2025 15:12:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C89816B0088; Wed, 18 Jun 2025 11:12:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3AA66B0089; Wed, 18 Jun 2025 11:12:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B50796B008A; Wed, 18 Jun 2025 11:12:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A7A0A6B0088 for ; Wed, 18 Jun 2025 11:12:14 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5E8961A0257 for ; Wed, 18 Jun 2025 15:12:14 +0000 (UTC) X-FDA: 83568862188.15.EC410A4 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) by imf12.hostedemail.com (Postfix) with ESMTP id 5A84C4000E for ; Wed, 18 Jun 2025 15:12:12 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=UCXKxF7o; dmarc=none; spf=pass (imf12.hostedemail.com: domain of gourry@gourry.net designates 209.85.219.54 as permitted sender) smtp.mailfrom=gourry@gourry.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750259532; a=rsa-sha256; cv=none; b=ebF8axvm2PScB+dLOaEFFSSZHd2LYOQ7+MifQl4LqulrXxyPdZj5KBINoNTzf04G4gXhJZ lkP4kbOUIrgAoB+QKMhIU7OexIfEzNp3L4lbV+paGu/HewTi15a9IQx0GK0g18Omg4qMZo tWVj2OgH2ofde2A0cgNUiZ26YikZO3E= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=UCXKxF7o; dmarc=none; spf=pass (imf12.hostedemail.com: domain of gourry@gourry.net designates 209.85.219.54 as permitted sender) smtp.mailfrom=gourry@gourry.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750259532; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8w7ovcA+eQ/2b8rTRZRntXptSXxd0DShnhC4amsa/B0=; b=axZG5c60BIsBhtVLr9DqpjI+jrNRPyad3s50wDpryRLEWlMeoMEtBNMwkJbe7a0JJfmVr6 U9JB83gxBWy51DjozKI5oHX+LSawOyteM3n6EYjRNHMIIOcdmGNH7c+MDvrCluHJvCoJqY JpzdzqF/5arlEukX9Vy8Hyv0AWQYpbU= Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6fad8b4c927so60184596d6.0 for ; Wed, 18 Jun 2025 08:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1750259531; x=1750864331; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8w7ovcA+eQ/2b8rTRZRntXptSXxd0DShnhC4amsa/B0=; b=UCXKxF7oUP+cScwYfMQgPZM03EyQS0A0B/G9hUxPIC+BldK2vvOxhxCjvKj0UyloST a2YvZTujewyiJD5sg+a/iyTYe96+Lgw0rU3yUIje7t4BcJE3ffjcH7JI9A2fEnD0VuNl rz0z5xImi4SqAVFZdnRoRR3KlmfCCZH2BZ/fOzFKMcVFqJoVNbssIh6ICkX8zmz1MiQZ yoscyCBhwdczVFLkik0cnKMt/YFzTAe/GT1RTmJ0PKwUoAL8sSu5JWE5LD86/QqiZd36 RQLHVXkIH/QfE5qt6sTfdVoRcgAD6e3s2fGdaDPbTTHvFjHG9gS2MCzgsLrzaGCycCAS /4Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750259531; x=1750864331; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8w7ovcA+eQ/2b8rTRZRntXptSXxd0DShnhC4amsa/B0=; b=Bg+V0v23BH4xVX9aM3sx96941JJggLYKerWPdoSYt6d/BO+fmlYY/GNivBDedaIJsO U4RbpqoHslmbXTWUHTtAtRSWTOregx2lsK19bAJxmCx/+jxZufuWUS312Fl/rxPgA//m fBvqn2dLbtNy+1LO8ahOAAWcxbnSkEBL4hxAChbi5OfLKLPN4nSCyIQL4Km47POh8WPF 81F8Hl1ytyiebiXFQLUG8/punzMMQbTcIvAaj/0GbNqWGoMzoROomZN2G7JnVk+DGr5M Os2ug51R4naCGOORigbh1RoauRqUaKdcfFV4IXUUiWO2WR1fNi+NyCoB1/OiuluAM1V9 m4pQ== X-Forwarded-Encrypted: i=1; AJvYcCXSD6gtT/sv3uY6WUor5mbOfbLaVkimg6x8RftUo0NklNd2DBwOU4f7uD8UMveVHNLJ2I2S2CtXLg==@kvack.org X-Gm-Message-State: AOJu0Yz7GPm3YxeCZfc7jGBkAMCOolI3jQKNCEQJzlM9xqgI8Ix5ORGf pJOTQ8u0yEW3DDWkynrfZ0C5k41fP0Zrq1zOinNbLbCDsi98Rbeqh+3shljnASeUCYU= X-Gm-Gg: ASbGnctL43k77UP/5MkJV9UyGv+jwxUkg/8IUZFJaeJzfcbR+IHZA+loWhBBquYPXyP qaFMBSAUHADGX9OFhVqbev/Wjeahs70SI3oSuNkwla/wXrOXn6N0QrdQLY5UuqJfVL1aF1+nQGN 8boe4yqZFxqw4U/ojgiGMJiqE4Tt/IMCfBE1LQhX9uze1N3up0s019PUo3tMybhyk3AOCudPoMT LYFj8qrvhxk2J13Jd3BJuDj7WaU4ySyPA53tFLolTE1amnQFDJq3IdK5POfk5vlTsBSSmk/NTiM ULoLMQGiF5U6k+DIqH7WXoBVtKDFnCiPuO+7xzrgju+3ZNUDzwfGM1PhvyiF6aJ/Ho3o X-Google-Smtp-Source: AGHT+IHofhP9BiiWq9pfl7Z5RgEudETJ5GYEen3cpQ0dOiuu8S3eCNtXQb4YOLf1G9jX/1/pyfy2rg== X-Received: by 2002:a05:6214:570d:b0:6e8:fbb7:6760 with SMTP id 6a1803df08f44-6fb47725d95mr260081446d6.1.1750259530934; Wed, 18 Jun 2025 08:12:10 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F ([2620:10d:c091:400::5:cf64]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6fb4cca79bcsm45456016d6.6.2025.06.18.08.12.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jun 2025 08:12:10 -0700 (PDT) Date: Wed, 18 Jun 2025 10:12:06 -0500 From: Gregory Price To: Shivank Garg 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 Message-ID: References: <20250618112935.7629-1-shivankg@amd.com> <20250618112935.7629-5-shivankg@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250618112935.7629-5-shivankg@amd.com> X-Rspam-User: X-Rspamd-Queue-Id: 5A84C4000E X-Rspamd-Server: rspam10 X-Stat-Signature: 6w38af896b9di6x46rwai7f3361o5wc9 X-HE-Tag: 1750259532-770859 X-HE-Meta: U2FsdGVkX18b8z0Il7TziwUhyeAClyTkQsXjyx3mNOpCW92pOybitkgEWcYtqik8iW55YOE5yvp+VSMmXLM42VxtRbz7gACbG2tz/DmMGRbQT+w4TwtehoaJafeK3OoBhOH8sR0UVpvlihVjhZMG8XeD2eE5hf6xa1FCjb69FLf6OfN+VC4p5PDq2nPnMaJrUbJav8mjwrT1a6ryBnYeEYAkazfRNsiXYc9D+kkhdot97lT+xfspQniJv2AcPFtWfHVe2oZZiMDGdUW1lVWLuxtQDIABC9P85+VGpus3UyXFmxynEn4JNRoqrIz7CIpeUdBR6wxuG80W3avVOQmX/v2dnyKqsV6XOMdDLaKIth65S/bwnZC6vl7toZXIkPx/021HX/V6oS2REtWEoXl4B+kDy4P3wvTjwviMtev/KhQZjZzpesLrlnCShTetZDTxuVhJQbHDpLc2J7LQXnShUJLhzQqSvcNwGP7n5sdn0uaBgsPc7YRJXyj0ExxcStlgAEEJkXAoyGFwtj4lc7ZkOelYkefirLdWk5Fjyo4G9j6sgoIbBiiqb46Je6Nx7k1TYusTEbXUmlxDgmS4lD57d7bCiv+kzp/h2Dcgxvunq7pvAoXqZ81QRLdF7YnUYFbmaP2gaOTjZcqMxTYcmT3dBcxJhwi8r091jVXcwjuKdxpsNttqRwEViYFVI2qDnuClYMOjqNWAVeZZOHsMInAnSem33aCV2ZnOponqb6qxPjWjdrOCV/F0H0YKXrmJP/0Z7usjAvd/K3x/wMiYHfa/nqkKFu0VKcttID+IAmgusNZB6cZSqwclBGzeTFFm4wIZgPamCNphw7NeHHtJanFNn/f5ZbR8yZwJr2DxE3Qff8V36/SRfnDGEY6BATpI5DsykUtQL13mZVcdwANhkHcP3C9X7GC59Tz6zWtLWbdeantpFY2KWpjdEfRwYHTA0P8zjmAtVq8sszGouWZ1K3e QQVh1gz4 EhGYr5D3yocBh+fOJGCnNPJ3rCqaPXkunzIOySzY7tLLizQ08xk6x2nZjpVHePdf98SGniZcTdEs2JEFdB0Itmwl1+3c6nz6UqbXF5h/ZYcKjT/BvH7rJFhe2gEmHA7nIXkfIDLUQs+XnORz376bpALc/LSdq3dFDiX3gJmNQubgR16PPCU3urkoh3kLm4awFYmovZaSjLoZMsyN/q/dZNcNMtseyTiGYS0pVxiPfvK/TLvLcW9aDkpd6TF0LTNS0LLWBWyeHACd6pnTgg4/sPKL2DzdWzwI82ggoDU+mk3ZmfOQEvV1S4IpbePUJNjhtbO/ItUaVFvLfMalUyHkZAmOqlHWBNFE1dQgimDV5mxxAbDXzw/bFIOq4F+wdRbdPlsDtH73VEQU0iQo90zV+SZ2J7yWMHCgv2/3gOPnUKTqTdJxC6GTvmDO88BteEN7WSTEUxTEodUTwlIytmhccCFmOmfZiSvS+K4dy/eVKz7fOCGg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 > Acked-by: Vlastimil Babka > Signed-off-by: Shivank Garg > --- > 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