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 F2EE3C282EC for ; Mon, 17 Mar 2025 15:05:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DF30280003; Mon, 17 Mar 2025 11:05:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 46874280001; Mon, 17 Mar 2025 11:05:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 330D0280003; Mon, 17 Mar 2025 11:05:39 -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 11FAF280001 for ; Mon, 17 Mar 2025 11:05:39 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C2B53515C3 for ; Mon, 17 Mar 2025 15:05:39 +0000 (UTC) X-FDA: 83231367198.05.1B14A67 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf29.hostedemail.com (Postfix) with ESMTP id 2954712002B for ; Mon, 17 Mar 2025 15:05:36 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="cYzQJzQ/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of tabba@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742223937; a=rsa-sha256; cv=none; b=6+v3WrjunN0IeJS1t24C+ScqG6bjz1na9z08BpoN4nHZg9COGPNekz2WIQFRUTxn595oLV b+5sPK8/1RfgmJEpjaTTC3FTOPt7jehd+lpBhT4UbDttlE2skb3oXPgEruiIzGULqRbSK4 qlGo+Ai/7PM0TXQdeBRoGuXQwX2hwqw= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="cYzQJzQ/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of tabba@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742223937; 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=Q6acMYyVpnTlWp6vf280bC/VNTF7hHxsvj81f2AtrN4=; b=QaxApyD5nWgtKWKMk7UVNJDz09ga125PNZsBhXyh4DVvN9FoBekEAO6m+oJuYuQc0T8fCv 8LpAUyybMPauFgcytFf7eXNnP9+alez1KUaWhEaVFkSF06c1tpomcifs2wI5alclpOFyMA nq2y0uZx4w5VXtcT64mcTQPoIJc7gbI= Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-476693c2cc2so37541cf.0 for ; Mon, 17 Mar 2025 08:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742223936; x=1742828736; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q6acMYyVpnTlWp6vf280bC/VNTF7hHxsvj81f2AtrN4=; b=cYzQJzQ/NO+Cc4MkUH2GfR9kouJJ17V/gkJNA6coJZJBy7oG3k9MR9qt+7T0fm2M6+ tC6IJa9CD/HlDh5Qhk6orYqZVa3m7rYKS93X8r7GaU4BiQ0DAPznsNTkx80p4+8g6k9y wKNUN+7QV2gfye/yZBUIg6UqBcIo/zunwpQaQ8E7oXMjJMGyx5jzjW9Lmr503Xve4kL4 l8E0WFCunAZHQqKyqNct24DDQNwrIai7bWpsGhoL4LSzP8lWRXnLbmyMm4+t1tEHjnDB jhUyj15Ypw0s6UHetIEnu6GResDf9M7Oq2zNW87Ak3QA+ijEZ4KTsrgD5U0WnNyGiRXo B03w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742223936; x=1742828736; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Q6acMYyVpnTlWp6vf280bC/VNTF7hHxsvj81f2AtrN4=; b=kc3eyTTXIJAUEX1A9FJzsl8z1/j0778F8sOJgNzYkvoNdmZ83WvnQ/dUOS3Km5h5T5 H+9OLlr93ztKAHQeg77xOyWl7VC4LVh/R2hZsHgGts1jGA3pr/3OpnSiiR8MnFq53Zwi VRf9EaEEY543R6l9BoDQQhoHF6MQ4ayQ7jeGrI0tw+TfbXxaoCIDmHMSpJhbUqMnogW2 839JPRUVqDa49sm96O1KKQPLeoNClnq2Cf0b9TcJPNO/jb2FK5oCyCuGbGSOIixyl4FB KCwjWhMnyeTpsA+ZL7D3Ha3ah6qa6PDPjTO3gCUX1IW5gOCabfQRVF+aPwIIjwgghosY a0Ow== X-Forwarded-Encrypted: i=1; AJvYcCWPVpPaCAPH1AfbDg/CbYGkIPq53xY3JJ4aaQfvlHN2lKF63aXgsa8dyhch/n0doE6+eF1ezOMi9A==@kvack.org X-Gm-Message-State: AOJu0Yy/sarXq3Ssr8jewChf0dRZ6jWTRF6sak3bTkCqSJdUaHvoHFit jju+8hhwczb2mLBd8s/UDpEfuju7qF2yaYUCxLvuMW+beBWH0bfKcgmz6OJweX9uaLYEIOwaRx3 jHf8twqwerN+qCsld0pV+afKKCxWkwjnL3HEr X-Gm-Gg: ASbGnct54MfvoGvO9cN86VrpqqEr488U9i02N/8YS0+xWDrsDUiizlt2vaDnR4efimA YioH6/BGMs36PdBpdUQFE2cpg8CQGYEuPHtF4BdQWpxPkTDmNzGWeRbrCaPamJEouy7e55I+ysI uVZb+yJES8+7rE6GL/Kye+MscR X-Google-Smtp-Source: AGHT+IH+SnQ4554b74aP98WRux3+caKdpTmocH4nK8o2u2lfK/Pn6Hyq/zWKssKls3zXLlkEqDdUuIxYh1b4SlHlcSs= X-Received: by 2002:a05:622a:6182:b0:476:fc5c:fd27 with SMTP id d75a77b69052e-476fc5cfeeamr25651cf.22.1742223935968; Mon, 17 Mar 2025 08:05:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fuad Tabba Date: Mon, 17 Mar 2025 15:04:59 +0000 X-Gm-Features: AQ5f1JrRC1We58imXbf1zfAv2Rf3a2pvMKnkCv_X6pPugKz4Jk08Z4RTqdk2G-k Message-ID: Subject: Re: [PATCH v6 03/10] KVM: guest_memfd: Handle kvm_gmem_handle_folio_put() for KVM as a module To: Sean Christopherson Cc: Vlastimil Babka , Ackerley Tng , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, isaku.yamahata@intel.com, mic@digikod.net, vannapurve@google.com, mail@maciej.szmigiero.name, david@redhat.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com, peterx@redhat.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 2954712002B X-Rspamd-Server: rspam05 X-Stat-Signature: cipfnpmkncpafceuahk3is4chbk69htm X-HE-Tag: 1742223936-580180 X-HE-Meta: U2FsdGVkX18zGJmuRAX0PZNnY8zEUMbqVTJItzecNuCswDEWXjbyJrrk1f6Oj24olQYs2nqYRtqh1a5vtEYeJR9hblDQXlQiXpMystW1dzOLqNDN6Xb9GLzSs2c35HMIrmN1u5eGGIpMDY9kfJgGRF9Tm1noKaPoEyixWca+UWPv4bVFuNPmB6SVq8EG18ABlfT2de5pWVThGrrwLSy3rO1d4/DQ5LzQU+4vZ4Y9cOrGDVqBEPB2of6ohALsZBqdph63++EOLbiAVwSuUqgXkcl4thZalCLT2gQp795Gp0kpiz5hkjAihxHd0M7sNxm0xS/+D9c/qdE/Vc+1JbwK33TI12QEK9SCqrglfdeGG8NQaFu5/ZEwXzay3fMBk42h+lifDALZU0MYFvgiyB5H9Kz9Il34Oyh3axmzLQ2BnqzqvqpenCYdNs7zhTkXtQ4CNvzjg4bKdrWE6t4EjC1VWcHaTIC6a7n1ZLakFTlCqOBDocGvgxRppwVHNBQSxxuhIAJnTvSPZSIxxZJvGYkXtrW1qIb66WKUFiF8N7cT/B7Agg9+lskoB0Cwvm9HHim86Ihs7MB/dSphDJ0V7zT2+6jZ2cPXLcRi7xfmoJMa5gnP/jgvzZR0Z0fxj0ocs38JCSpGGQViJiDRg40j5uKIYfofz/Tw19JWBezCWeM7cTr5HYmZWtm2Zm1scGKOCUnQGbxkHsF2qK0E/vtSIBch58Ci2T4rOCyGbq53D/r0Alte6FLEzjRC+kswg5ojoXlmI4wgQeNrJHe5iQ1hBAjj3+lzHJ/r0mom2hiPSIsCb3ahheWHPJMX1Ihk1TZIPQsmml1Mp7OvLFu/+dIEReiGthGzALmXv4oVKktUrry7ZmObyVYa8cLk8s9ADDYYyLh9Magkz0ms8L5QhE9iWyq9X9esiwxn/FYOck/Ol7b0We7wRgJOd5L3MxNQr9QELp1jlvc19yYR5seXoflQwGf s4QFlA+j 5Zbd7eCAIALPftY5BqFblP7mSLWBR+IqAvd4eTAiVygiUpky1oF0Cttj0RnBjtaQqjhIxIAgQrJ30mxxrKJ9KrJd96IdmKOCZPT3xgTNuZnLjI+TP8eNuCEeJDe5z3ynD81gdSZzvhW5FdfqKeoQYGobXhUTsFyt7B9jsYSU04GAMYypKmkuupLKFhbI271V6OorkLQFJrNOYhTROvI50YRMG7iNPo9Djr6Ne7scTD3NCFEKWcK+o1m6zUPsrc3KATbxqTMF78pbUgLEwxU88Bvxk1rZhcMZr4Yb+3de9OC9QJu8Ssnj/J6uLGshtIqA9Fg0zIGuGud+/gOviyBGGEV3Jfw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.056434, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Sean and Vlastimil, On Mon, 17 Mar 2025 at 14:39, Sean Christopherson wrote: > > On Mon, Mar 17, 2025, Vlastimil Babka wrote: > > On 3/13/25 14:49, Ackerley Tng wrote: > > >> +#ifdef CONFIG_KVM_GMEM_SHARED_MEM > > >> +static void gmem_folio_put(struct folio *folio) > > >> +{ > > >> +#if IS_MODULE(CONFIG_KVM) > > >> + void (*fn)(struct folio *folio); > > >> + > > >> + fn = symbol_get(kvm_gmem_handle_folio_put); > > >> + if (WARN_ON_ONCE(!fn)) > > >> + return; > > >> + > > >> + fn(folio); > > >> + symbol_put(kvm_gmem_handle_folio_put); > > >> +#else > > >> + kvm_gmem_handle_folio_put(folio); > > >> +#endif > > >> +} > > >> +#endif > > > > Yeah, this is not great. The vfio code isn't setting a good example to follow :( > > +1000 > > I haven't been following guest_memfd development, so I've no idea what the context > of this patch is, but... > > NAK to any approach that requires symbol_get(). Not only is it beyond gross, > it's also broken on x86 as it fails to pin the vendor module, i.e. kvm-amd.ko or > kvm-intel.ko. > > > > Sorry about the premature sending earlier! > > > > > > I was thinking about having a static function pointer in mm/swap.c that > > > will be filled in when KVM is loaded and cleared when KVM is unloaded. > > > > > > One benefit I see is that it'll avoid the lookup that symbol_get() does > > > on every folio_put(), but some other pinning on KVM would have to be > > > done to prevent KVM from being unloaded in the middle of > > > kvm_gmem_handle_folio_put() call. > > > > Isn't there some "natural" dependency between things such that at the point > > the KVM module is able to unload itself, no guest_memfd areas should be > > existing anymore at that point, and thus also not any pages that would use > > this callback should exist? > > Yes. File-backed VMAs hold a reference to the file (e.g. see get_file() usage > in vma.c), and keeping the guest_memfd file alive in turn prevents kvm.ko from > being unloaded. > > The "magic" is this bit of code in kvm_gmem_init(): > > kvm_gmem_fops.owner = module; > > The fops->owner pointer is then processed by the try_get_module() call in > __anon_inode_getfile() to obtain a reference to the module which owns the fops. > The module reference won't be put until the file is fully closed/released; see > __fput() => fops_put(). > > On x86, that pins not only kvm.ko, but also the vendor module, because the > @module passed to kvm_gmem_init() points at the vendor module, not at kvm.ko. > > If that's not working, y'all broke something :-) Thank you for your feedback and for clarifying things. You're right, with a reference to the module held, no one should be able to unload it as long as there are in-flight references, no stragglers. Nothing is broken. Will fix this on the respin. Cheers, /fuad