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 2F7D6C36018 for ; Wed, 2 Apr 2025 23:56:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20280280003; Wed, 2 Apr 2025 19:56:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B1FB280001; Wed, 2 Apr 2025 19:56:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07AC0280003; Wed, 2 Apr 2025 19:56:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E0EB4280001 for ; Wed, 2 Apr 2025 19:56:41 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 98EE3AB9C5 for ; Wed, 2 Apr 2025 23:56:42 +0000 (UTC) X-FDA: 83290766244.18.5E4CF07 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf16.hostedemail.com (Postfix) with ESMTP id D7888180005 for ; Wed, 2 Apr 2025 23:56:40 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HZnMSpGO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of 3t87tZwYKCFICyu73w08805y.w86527EH-664Fuw4.8B0@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3t87tZwYKCFICyu73w08805y.w86527EH-664Fuw4.8B0@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743638200; 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=4vIm6df2fo6Fewjd44SIeiPxj02slwP9HDZ1sfVq81A=; b=zkWuJijBRC9n65+Qgxux/ogex6LQWfrGka3fqoWsYX50EErzH+A5bPQ5YYCmkiL/arcTUY 9QIl9xrgtv1ps1NKeQ+n6mdzu69dMebTqEUnvxqT0i2etL8+UnftLdHWohizAkJM7D/Hrt BpETwmnM35Xpfc+jgdwc5pKESR0Yv1U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743638200; a=rsa-sha256; cv=none; b=cRNbT2ZyPUG3jsGVBAqm8AW9Tc1lgjPiBZv/KzdhzxUB1DUQgPVntp8TZjtE6MbjyulF6+ z3z5Larb3SH5m26SMoXgs3MTw/FpcvHRgt+tgXDBnkuuHZ4Y9sVfxpQoFcbOXywbrgLc3S uCaAhBK2CfMFfXnSP12qgGkQ94BfnAI= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HZnMSpGO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of 3t87tZwYKCFICyu73w08805y.w86527EH-664Fuw4.8B0@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3t87tZwYKCFICyu73w08805y.w86527EH-664Fuw4.8B0@flex--seanjc.bounces.google.com Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2254bdd4982so5268545ad.1 for ; Wed, 02 Apr 2025 16:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1743638199; x=1744242999; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=4vIm6df2fo6Fewjd44SIeiPxj02slwP9HDZ1sfVq81A=; b=HZnMSpGO7aOo+6oDRTwRw2YyL1MsREBYutrMcDScLYcxWzG8fGMaVtgCdPIb8Ta4xb Clfechip3vX9H1tqweX8vlYA7sMVk9wBBHgwPr0rcFv0xmvz/o6g0gwZk/R+S6j6iawH 4mVIS+E9fzl2lVFL5YbgVMsR3yD/Lhhiw3ADpeTchDnXJOg2Rsb+6pCumuk+f1sOYgF0 +TZpSXk98/UURzKl82RpVPi1ht197RsnEjIePOAcRZcjfshOs8va+npppijmgECNquIA InN2uUUe8hQMFzeGUMeZrghz57uW5O+EYls2AT33l0MPdmMrmOCIW2RWLn+370FZTy6/ 3xbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743638199; x=1744242999; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4vIm6df2fo6Fewjd44SIeiPxj02slwP9HDZ1sfVq81A=; b=tvbx30Pa3CXI+AxK8et10DcXkEaPibU2O/O2sN1jIu+TBbZLrdw6OjEl7K6P/FIQc+ beVPQY5SkW5NKpdN2GV9d9PiVV+OhRAKcIM3TkEKJ/Fo20rYA7vg18GXL9zj/4Oe+f4r y9q51pC/wTZ9K7R/8fB8qUCAZPuAc6PnX99Yn1kbpT+O3iL78E5oc9zeT5NGThBqbuo/ q49dWxbjg2TJZpG5czIgKJWkXrWBUWdDyIBmaK4rz8pG0IqfMbU78QPfgVW24sQd1jYZ +VZMQpUVUlR4NaHMfOI46eW2F9I8LSd9NK+e2lBy4DbPSNtBfys3aU2FBAp8h8BQraC+ ykhg== X-Forwarded-Encrypted: i=1; AJvYcCXh5gQuoMOnvAGgq5SzCM2xtzi7jjgATXka8uuuAO0AbpCQBc1BlRkcFRNIh3FcUE4xwviXpb+SRg==@kvack.org X-Gm-Message-State: AOJu0YwqbtVh/yer7eJZAQ5uHEVqqQRLnqkxTmLNMYJ6xteFsNK9DC/3 DC2JyaALiLFnw8iiahSrjede16n1MSMbMAXABCP/LfNciTGkYWTw8wTT739bkBR2lbn4IXey66F IwA== X-Google-Smtp-Source: AGHT+IGFMwLksy4XiBzz9HIDdqWCU4ltuYagyIkABhVEC+CyeQTlhxy73EaRBIaDFauOrErYz/GyNbcvcZ8= X-Received: from pfbg6.prod.google.com ([2002:a05:6a00:ae06:b0:736:3d80:706e]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:db05:b0:21f:1bd:efd4 with SMTP id d9443c01a7336-2296c65f460mr54081795ad.19.1743638199570; Wed, 02 Apr 2025 16:56:39 -0700 (PDT) Date: Wed, 2 Apr 2025 16:56:38 -0700 In-Reply-To: Mime-Version: 1.0 References: <20250328153133.3504118-4-tabba@google.com> Message-ID: Subject: Re: [PATCH v7 3/7] KVM: guest_memfd: Track folio sharing within a struct kvm_gmem_private From: Sean Christopherson To: Ackerley Tng Cc: Fuad Tabba , 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, vbabka@suse.cz, 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, pankaj.gupta@amd.com Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D7888180005 X-Stat-Signature: buqcam65qwx66u7juzksdqsauqm7s81t X-Rspam-User: X-HE-Tag: 1743638200-143955 X-HE-Meta: U2FsdGVkX1+u/KdvzEmF1zXsbBMculrFtCl5ggiAql5N6M8mubFGHNoDJZ6Y5QPRJX+sxXPkBOqco6nes/Hpk2jv/MvT8iXGECjJMnhhOTdYd1NrzId/0tBRQIAWHstnzCSB+3dKN4Dtpk5IrgmL0senZ1aKlcDGM3A8oDiVxoCqkgLhJ2+G37nXnfEXD5IPxu5EW6qul5tBCeh8hAIpyrHbKWQQDIRC8J4mMnmKarA/rcuVC5YZFqULqSafwbvkFPuv6+2u69Vyw5pNmCOtmjA+zuATFCJAwPvYhoAKELHPWKXPSFegtudrXg/VqHOQ69QFoujR/GDOtIO+pR6X5jdJhzQH8kOuPPZIN1YFIeUF7CpcOuLbaKsLrF4HEipBr6+aBBQroOrrOsvNh6bZ50BzSXzNrCoQpQYKnqrle93JSKXI8/BQX1LmxtllMj5IMSV+TthcUqQrgCsNZJOVIOdOrikamGIvraftNvMMKMMqzmxrA9hBpcXI52t99bcYrLoJEwEHvQdelNayTrZEjmVbldx2gbGb7DW5GjzpM1p3l+VStxXXzyhF98xEXVeiCh4yBwHmau3kz9dp3kyfrKvsmb+Gkt9C6y6ZmW0SchXikGFUd8d3kXUgjLwdupliqUYbi0G5eBrCJGqnoScuq7CftvC6yQyQ4ePxm+uoBD58QYcUFVcfeGizDdx6FA+0mj2sdR3nfzNn2E4rx6/r6HQgfX8VWRKqJ4Fsp5zkyrXfvWrWvNUc88/IKgYtxvxCcIP+2Dln9j+S8JO6s6F3MYZaH0Z72O+hIajx6E42EWoROX4y8KD906Zy5T8SLwd+IWsq95K/z753zBGWajAhKnxVjkCEJ8bGMxLl73Ib8YIZCPPut1o1hyJcDmOtUDMbWRD1cEwCfeoWxnACi9qMsrvAj/KKSn2RNSqfNtFNuPx0nIVQlIhc1mpd/FZJtN7sV61ycPHjZfnVfpCmBxA jPOsilr9 t3eOXxDmBHaNH0LnHxUHeS1NloJxF11bF8gDk1qW/9MRlzYHc4r1VHvoHGKL4/8pK5Adldx2/341uTS12ZGOl4l7YDJ7nWWCBnoHLVuvxa2j+LKyMyFWInxgKsCVQhBoolhMiTOkoppgQjsGwuiumr1VnmDXR6dJLGgNB3iuebmyH3lKTCYAJB/UD2jLqxqc0IezAIbT1NzjwvmYlFNAVOWX6TioNfqUo+KiKX+EB8LcYffaTzVCnTV+Hwi52b0Dj0BoHTkhLm4wwJXUqsozZ9YeaFyKWTuLA/BWKxHg3HQvx0exQWAfah231V9uLD4bRClwKmCderv/rEguBPcHBANF/mRBmLxsci+jH+apQtLVbqD0g8nq+Iooj+cSCphH+TKIUoz+SYjtb3iFXjWEUL1fRWbyiVdpoLHa6PDkD9cSBjgch4UmIPIg9abHyAOMRtsxXbAjRnchECVTYdN0SQj+5Y5021boFisliYese2rX+T7BK0Cm1GrOCnWkae7GK/JFYqMwdhrvmM6w5OQHSKvrP15ogDqe5c6gtInXxlD7QCdhATAJWrY1GO8eJNRKr0yw/xJNo8Foy5FqTK0k8CoacuuGQEgXR/BLm+S0kRzQy2DF1MgCjvgmFzrgJLaZ1tXjOPKKjC6NX2SSEgilC8oXY0c1TN8PSZ+F/lP0KwpAcIY8X2ra1H4OAAKvb+t58IPm16aeTHqxDBvA= 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, Apr 02, 2025, Ackerley Tng wrote: > > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > > index ac6b8853699d..cde16ed3b230 100644 > > --- a/virt/kvm/guest_memfd.c > > +++ b/virt/kvm/guest_memfd.c > > @@ -17,6 +17,18 @@ struct kvm_gmem { > > struct list_head entry; > > }; > > > > +struct kvm_gmem_inode_private { > > +#ifdef CONFIG_KVM_GMEM_SHARED_MEM > > + struct xarray shared_offsets; > > + rwlock_t offsets_lock; > > This lock doesn't work, either that or this lock can't be held while > faulting, because holding this lock means we can't sleep, and we need to > sleep to allocate. rwlock_t is a variant of a spinlock, which can't be held when sleeping. What exactly does offsets_lock protect, and what are the rules for holding it? At a glance, it's flawed. Something needs to prevent KVM from installing a mapping for a private gfn that is being converted to shared. KVM doesn't hold references to PFNs while they're mapped into the guest, and kvm_gmem_get_pfn() doesn't check shared_offsets let alone take offsets_lock. guest_memfd currently handles races between kvm_gmem_fault() and PUNCH_HOLE via kvm_gmem_invalidate_{begin,end}(). I don't see any equivalent functionality in the shared/private conversion code. In general, this series is unreviewable as many of the APIs have no callers, which makes it impossible to review the safety/correctness of locking. Ditto for all the stubs that are guarded by CONFIG_KVM_GMEM_SHARED_MEM. Lack of uAPI also makes this series unreviewable. The tracking is done on the guest_memfd inode, but it looks like the uAPI to toggle private/shared is going to be attached to the VM. Why? That's just adds extra locks and complexity to ensure the memslots are stable. Lastly, this series is at v7, but to be very blunt, it looks RFC quality to my eyes. On top of the fact that it's practically impossible to review, it doesn't even compile on x86 when CONFIG_KVM=m. mm/swap.c:110:(.text+0x18ba): undefined reference to `kvm_gmem_handle_folio_put' ERROR: modpost: "security_inode_init_security_anon" [arch/x86/kvm/kvm.ko] undefined! The latter can be solved with an EXPORT, but calling module code from core mm/ is a complete non-starter. Maybe much of this has discussed been discussed elsewhere and there's a grand plan for how all of this will shake out. I haven't been closely following guest_memfd development due to lack of cycles, and unfortunately I don't expect that to change in the near future. I am more than happy to let y'all do the heavy lifting, but when you submit something for inclusion (i.e. not RFC), then it needs to actually be ready for inclusion. I would much, much prefer one large series that shows the full picture than a mish mash of partial series that I can't actually review, even if the big series is 100+ patches (hopefully not).