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 7C7EAC282EC for ; Mon, 17 Mar 2025 14:39:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3426D280005; Mon, 17 Mar 2025 10:39:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F197280004; Mon, 17 Mar 2025 10:39:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B947280005; Mon, 17 Mar 2025 10:39:01 -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 F2380280004 for ; Mon, 17 Mar 2025 10:39:00 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7D88AC014A for ; Mon, 17 Mar 2025 14:39:02 +0000 (UTC) X-FDA: 83231300124.09.298BEDC Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf13.hostedemail.com (Postfix) with ESMTP id B5CD720007 for ; Mon, 17 Mar 2025 14:39:00 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AqLJhP8d; spf=pass (imf13.hostedemail.com: domain of 3AzTYZwYKCBIAws51uy66y3w.u64305CF-442Dsu2.69y@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3AzTYZwYKCBIAws51uy66y3w.u64305CF-442Dsu2.69y@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742222340; 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=9Op4uidlCpeYwzoDgf0iPKy+/ekUTh6FlGoKnBfWlUE=; b=uTdWoOhXRM4m87jdeeW/Q7dFEFvElxIJJTHYqCa1bCf6YwR0X8ibPpeoQ0VYXVzcgcBB0z 8zYCb3iInnznEYSD/wTfThfgkv0tgFsuKAcQbfAOXom/R8gPSuMYJyYhCZ5BUVy7l7WGsW eX8YxuEMu5cMdQAsNyIzpgKq8AHsTT0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742222340; a=rsa-sha256; cv=none; b=jTPgVEmnIspiUhShc0tSIydCe5ySftn1gw3Lm9dFAOI7ZxST2nYUb6i99IfC2rKy/m6aVh z2BZFIyWadRZyc53qakcYf5FDhXDtxK8gu+HWK6miGVO8a+xegyrap0LM27JDPZLAmdC0E v4b2H+6ObUD1TemMpyl8nHk/DlWdayc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AqLJhP8d; spf=pass (imf13.hostedemail.com: domain of 3AzTYZwYKCBIAws51uy66y3w.u64305CF-442Dsu2.69y@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3AzTYZwYKCBIAws51uy66y3w.u64305CF-442Dsu2.69y@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2255ae39f8fso93864785ad.0 for ; Mon, 17 Mar 2025 07:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742222339; x=1742827139; 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=9Op4uidlCpeYwzoDgf0iPKy+/ekUTh6FlGoKnBfWlUE=; b=AqLJhP8dPASo4vMnzuTboEU1ALhR4UP7Quc4cxw+ooQMTiIKNQjuIHgxX/7AvG+9+f dgCkSiRpoGYXo+qEn8+406ScNoHK08MZK15ky28sSsTeFX7qnldoZYIgn/KNhqZ5KUsg FKvc/0S/bEDGzufeh/bcuEsshwQpUeApzGFUf50MkBwI3GN+/jg4X66wy48zYJDmnsmQ wxcKY0z7Yl/1Wfm/uvpzvAX27vbCSg+NILkEG8BL6ga9rR6mgtzMu95H4bMvIQ5sBVHP i13EwsStP2n3JvwMw5y14x1ic3DkUo7LMwLRjks9P9CElHu9IbbZ5g88lIg3aK9rK0a0 0rew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742222339; x=1742827139; 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=9Op4uidlCpeYwzoDgf0iPKy+/ekUTh6FlGoKnBfWlUE=; b=hZi8Vq+azJzqnKMqyY6P3jzSzvBk2FhAMKnkvto4aAvpMeKjJPLnXx2P7b+SSpXQ+M hfvwhaHeEnzPPswxD0eDyMQ/bkq+JCii4snp2vYb7lLOybI97FhMfiF1Ekj4tUlL4EBf sqKiekbLLJr9EO1OvzLwhf87bO3Pa+SDOz57TC28IMRJEog/KlUm6vXIezfolnIdxvgC ojLce/MeBOayT4MvfvwVdzBLqJFb+dnIwZwnNOf6aol13HBRvDkMT75flf8tAOcQ63FH pckX5hdBSozHMSt8i5pDPHGth3orxKdPL7q/axKOUcOniP/BxDtDImmLfq9kduqGRXgM 2h/w== X-Forwarded-Encrypted: i=1; AJvYcCVz8cth8I1VA9O3QJk8yrdA8HxhdzjbTZf05MQBTIkeXjXxZTYWDqzTrSROjFlp9yOyi413ZgYEBw==@kvack.org X-Gm-Message-State: AOJu0Yx4M3CJkSqp+6+QCvh3lCB0eokr9Ne3mbZ1hkMQyxuyRT8VQG8s k/NRSQP0BeN8YrfTkS3iSsbovWI2J7A+l8DnKv2QFAn7TENcn0xNt9qhbpNq0qrwsFwZtBM2+aR Zlg== X-Google-Smtp-Source: AGHT+IH+0K/tTKkWUqTn+JnWKj5LdFmhPjMwWAnay0MeDaFc2pDrra16+lQ6NN5tULJSNZlBoZ6guoXVZ1I= X-Received: from pjg13.prod.google.com ([2002:a17:90b:3f4d:b0:2ea:29de:af10]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5247:b0:2ee:5c9b:35c0 with SMTP id 98e67ed59e1d1-3015214a808mr14301008a91.9.1742222339603; Mon, 17 Mar 2025 07:38:59 -0700 (PDT) Date: Mon, 17 Mar 2025 07:38:52 -0700 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [PATCH v6 03/10] KVM: guest_memfd: Handle kvm_gmem_handle_folio_put() for KVM as a module From: Sean Christopherson To: Vlastimil Babka Cc: Ackerley Tng , 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, 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="us-ascii" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B5CD720007 X-Stat-Signature: 1f5wd53ne9xyrtx95mz879yxxpptjq5m X-HE-Tag: 1742222340-312711 X-HE-Meta: U2FsdGVkX1+Zp0NNNcViVvc2fY2EyR6vWrT6ExR5MVC4qJAwrbW90OkhaiZagOfBI9k8iuBfNlQYMOKQT93yjjs/xqHpnbbBH6NCcr/3pZrJZQftvMCqI75jeAg82Tk6AyXH8+1eiRdMm0lP89NnnluWxb7OY6wm1oGhihdJjQVVEdT0KdCXXdDH/lql68rJ+ZTqXf/WsEJvXlzhL2LKm0xFz37gSGH6XnRWtxLQa2zlgAddqJG6QmT9YsNaHZDylxrye33c6jHweBRTRRDXeGyZvolilZN6n6XTvur6WlilRjWsuPKEUqkhgnv+wgq9qe+z64JNRwmw1QqLlTg3drSmRGjmyWebIDqBwxHbHM7Mlsbjgt31zZ6Ubz37wog5OEyypAjPcaY8cUfoQoAwvowpWVnQWOFGOv7M+GbUa68LbESFZvoB9A95opioVDSZ+7u+orePBrFfkuUFbrJUz3KR9i+9200sDKs33wgAesmF85uXBjeCyWotLQcmj1mY3sgltFdZgr2LeeKwyZERky9Ko1O1EVLCwHTosiBcJmBr/HFdrTOEhupRr2ROdHp3pzND7Uqh1WlSWvIsyKeRpO2ghFeUJE8eSMJqrDb59swFmysDUvYVIZnccIQ0CiGa7+FvXq6Vagq4++LAlyzpfaMP83p94WkLZb4tfcXbsNqBhITfJb+LtqhIOEPMeZ5QGDTOxWhYGptvcpKpAUQ31LcqRLMU5tvXlHlSFa4S5rVEootSjtubaXFCjozrRQ5Y1pjHQ990UWuyjIsGxFuR3tt4dWoFzxUunocNAY1mIZJ7kdFo1j3PYFtL3JGM5t4+njRDU5ptZ8LXUczbby7nECqk0MJvpG4L8j2X14Nqrb2ZwIqJaZ9qVCVNRkQqS0K7CaLhDg9sE/QU6taLNfW1tuydteOzOAtywv8msWQPcst04w1/fDe67w14Zpo8Wik30S4wcXiTANsDaHme8w2 qrzJt648 H3aEPMc+jHIwohus0pYo1ColIdGGqwMNr3ezdAVpQdZtG8yCCYFFeblrNLvdrb8c6QgrDHCcItaWAod3LgNsxoMk2QsU9g1R8/FlOQcttT5zjYW9JlA/tIYLAuFC5WgaM/nFRcbZljXw+j8vxo4XAbbYroJVZhn/rzRguD7+omDL6EX/d2H41KbYmqea7Ed66HOrELlJqEJbZv6oK0ClNy+acqjvzYSi03g1AvEq0dxOIQhMEM/HRMtk+FI58vARx85te4ptsb/gwSnc9UzKeXpMRINl7uWlpgYTslB8s/QDNWawA4T7xUyldKWtfjJq0pWjeDAkbRNf25wl/tIQLQyFceHRTImgQQKJRp/Lws/QvblgX0H1Ag+07krydm3PoG5NJhBXEnE+tKDOSyWJxhkpSI3uUv4JhXCppH8ivr1508kuS6kedgzaB6rLSfIV1nlcQRGrGzGDHUtvv3QJdUokztY3qnXs6+0xZ19nHu5nD8KA/6HiXZmiXrQn6rEbZ7FmL6+ru8DwgfgVYWWXCUACDCX9SQz6KtNaR4m1EUBntmjqn9c4E3vjVjn8Be+W1YzzVKCrmlVhGVI6/PrgcPnk2Vodz/LOia5H7wbArUj9TDghe8ssFLNOprKv5+NBw6Xa3MLT2lvqiJMSvcGE0Kaea7R1WGoGuzYsy+lH1cQ82l1ZozXXB0jjARcwKUef2QrkKPYMQo48mP9s= X-Bogosity: Ham, tests=bogofilter, spamicity=0.007976, 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 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 :-)