From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABB6D32E12E for ; Thu, 25 Jun 2026 00:35:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782347722; cv=none; b=Up/nODXk+TLdcfJExenrq6B04JLXwKyPDC4NP1g6RUDv4Pl6siKEKIKL4ytDiPadjeWUVmkFTDRPYLVbOrfrgI1aVup4u+mVQEMKjy0ERSTMR6TxRVJFSp2VjNwnSsGHWW87I7tKiBCLFhbGsbqciiUn24rkWeGidNNc7DJOx+8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782347722; c=relaxed/simple; bh=f4AREVsRHfiF4PAbuxnn5TgCeRNzuQ0Pw+TvIFB8YS0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=HGnbDY7Syd37sRJH5dadl/koNSvKETtjdUr7fjsrMQ5X3KNks6ExK5v0lTbmVeMJ3kYgYl6Ga8mbkLJ9F8Q/TlRlUM1CMZ+wPF1IseJGtKY0HeQ7IMwBCA7oj6y9OGBNT8R4VS6HszqEOb5mwrFOVZupXi4SDAhT23TCUtc+5co= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=b6zvtV1p; arc=none smtp.client-ip=209.85.214.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="b6zvtV1p" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2c76be5dd09so10721665ad.3 for ; Wed, 24 Jun 2026 17:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782347712; x=1782952512; darn=vger.kernel.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=XNahi9jo3ln3x9OacQs1ORbpzN2GfmnsobY71bssZU8=; b=b6zvtV1pd9ygwuBS/nsicc/w/JFBgXi7+DIhzhsuqmgtllGzzTQNSsvpsNcVJJ6tLS bFxu/8FnOpAca9IN0DQ/frCnfVsRcsF9prm2n+wSUpu0Yfr1yK3TZQUmUIGy6m1PlaOd WWaAz34eVsJ432ODUHxw8x3Eyna+MfWxWL4XuXvWpLIpzJeKlFUBDwiMAudYohcQmUWI ztwW77cPJEQx08+y0xwbrfQp94CoFpFWTvmVVALF+rkHxDF+LMwjIngQTFnLBN5LCL8Z 5ApTmCpoms4cYEh1AkPcJbv+97Ui0/o+ZaWbsAqBb9ffZXNIyElkBqv4cm9JJVZj2JHY SOHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782347712; x=1782952512; 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=XNahi9jo3ln3x9OacQs1ORbpzN2GfmnsobY71bssZU8=; b=JtIBbPfr6M/z6Itb40+rQFbnxK9nWlZUKYZliTOb5bZNwAf91/cKCaGFGF3dFBawMe LkcdAZ2aa2QZC5GNzXBJs12VnWAMJ2YWu27DLNLoLc7G/w4N90CtHvrB66aQbAyKWuGO ISFHTUefMQ1GfxTlKXdJ2G83WmQdZT5nv2e4zCDaGhVaz0B7c8kOzB5YNnhuu8VgbfTf ye3zRcBfSIQcniHKX9Q6g2gHZ/SPKBiihZ0jxlC67EVu6ZS2ql0FIsgRBmve80TvWZ4T 3vclI/En6Dfww9njUVPG/GFKjy9S+4QaZ572KJl2Thejvgozp48NRGiH74Yk6wO9dAuV LwZg== X-Forwarded-Encrypted: i=1; AHgh+Rpm/9fy+3F8cXaVEAaYwmfLBV136LkZoGl2hofiro+Aiy4y9vkYyALxFgtjDf6f4CH/YEY=@vger.kernel.org X-Gm-Message-State: AOJu0YyTSTip+3iqH8OryoAC2p7Ncbd3CAV0F/zai3+QF8c8e0Uh0Skz 0O3oo31d6LyKNQAKRo4+F/PCXqQbUnmfuNzuB8uK/RqSQNx2kqMIbYqFY3m+aN6tcq+cHCeh17h TuVkW9Q== X-Received: from plly17.prod.google.com ([2002:a17:902:7c91:b0:2c6:bce1:2477]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ce81:b0:2c0:cf44:3b3d with SMTP id d9443c01a7336-2c7fc7579b0mr4179365ad.26.1782347710976; Wed, 24 Jun 2026 17:35:10 -0700 (PDT) Date: Wed, 24 Jun 2026 17:35:10 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260618-gmem-inplace-conversion-v8-0-9d2959357853@google.com> <20260618-gmem-inplace-conversion-v8-18-9d2959357853@google.com> Message-ID: Subject: Re: [PATCH v8 18/46] KVM: guest_memfd: Handle lru_add fbatch refcounts during conversion safety check From: Sean Christopherson To: Ackerley Tng Cc: aik@amd.com, andrew.jones@linux.dev, binbin.wu@linux.intel.com, brauner@kernel.org, chao.p.peng@linux.intel.com, david@kernel.org, jmattson@google.com, jthoughton@google.com, michael.roth@amd.com, oupton@kernel.org, pankaj.gupta@amd.com, qperret@google.com, rick.p.edgecombe@intel.com, rientjes@google.com, shivankg@amd.com, steven.price@arm.com, tabba@google.com, willy@infradead.org, wyihan@google.com, yan.y.zhao@intel.com, forkloop@google.com, pratyush@kernel.org, suzuki.poulose@arm.com, aneesh.kumar@kernel.org, liam@infradead.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Jonathan Corbet , Shuah Khan , Shuah Khan , Vishal Annapurve , Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Youngjun Park , Qi Zheng , Shakeel Butt , Kiryl Shutsemau , Baoquan He , Jason Gunthorpe , Vlastimil Babka , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev Content-Type: text/plain; charset="us-ascii" On Wed, Jun 24, 2026, Ackerley Tng wrote: > Sean Christopherson writes: > > > On Thu, Jun 18, 2026, Ackerley Tng wrote: > >> When checking if a guest_memfd folio is safe for conversion, its refcount > >> is examined. A folio may be present in a per-CPU lru_add fbatch, which > >> temporarily increases its refcount. > > > > Under what circumstances does this happen, > > It happened 100% of the time in selftests. Perhaps it's because in the > selftests the pages are almost always freshly allocated and so the > lru_add fbatch isn't full yet? (and that the host isn't super busy so > lru_add fbatch doesn't get drained yet). I chatted with Ackerley about this. What I wanted to understand is why guest_memfd pages were getting put onto per-CPU batches for lru_add(), given that guest_memfd pages are unevictable. The answer (assuming I read the code right), is that lruvec_add_folio() updates stats and other per-lru metadata for the unevictable lru, and does so under a per-lru lock. I.e. we don't want to skip that stuff entirely. One thought I had, to avoid the IPIs that draining all per-CPU caches requires, was to disallow putting guest_memfd pages in folio batches, e.g. by hacking something into folio_may_be_lru_cached(). But due to taking a per-lru lock, that would penalize the relatively hot path and definitely common operation of faulting in guest memory. On the other hand, memory conversion is already a relatively slow operation and is relatively uncommon compared to page faults, (and likely very uncommon for real world setups). I.e. having to drain all caches if conversion isn't safe penalizes a relatively slow, relatively uncommon path. If we're concerned about noisy neighbor problems, or outright abuse, I think a simple (per process?) ratelimit would suffice. But it's not clear to me that we even need that, because there are already many flows in the kernel that allow blasting IPIs without too much effort.