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 ABD0534FF45 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=1782347721; cv=none; b=hSlZ53sf6iF39AOQYZCk547+porIbzemYKldgHnjrcdj7hIgxFDrikPo6XX4/c2CBBo9NnvL5nMI3ZgZUg5z89WhS/uR7ZzHhz92j2j10f7d/NojzzkQrEEt1wZeqTWZySGbx68lQaZPjt5HvQu8drYDm2PHf2TbEMUcBxVf2+0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782347721; c=relaxed/simple; bh=f4AREVsRHfiF4PAbuxnn5TgCeRNzuQ0Pw+TvIFB8YS0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=pcxMvlW7m1kPoELGVO9mN74Zr7eUC9S2yLIhTZFBMHcTMI5RXYYjWskdalylPg0dezf/rfTNVyrjuNSgg+sS6PDUtIxfjcG7SRBKXK3hcgboaFfwv/bQ+E0zLBKf8Hg9QqoO+jFuHPwVed+nCLISlyXGgsZlSWIH1YdYoAmXLTw= 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-2c7ee3952d6so7076175ad.1 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=eXfflBtYXRkY1jb+tPY1pp5RzM0XQdTBdMyKGG17QlMdlnRz9AXP3oOADsAy4IyWZ7 y4qj/wqPPuoj7T7doKMCl0J5bD8Gy4EZfcAWxDzHC+nA0Ph22t3G2myGuOTETUOhwslw fdmQyWr8PFu89OIyMwEUC38N2K6rgKgG92PppF6chKuKdXhQDhgyaGXhH3q7UhV2/ALc vGaXaIZG9O6eUwQNqOywKDLFtiYIUWPR3yGTnEFsmHHI6qLM6FI83sMudm+ba0kmxwLd e20UOz/IY4EGMjp+pkYUDf9yUe7o2dtujgi+oLcN+Ri/v0DOa2wPuXTqXa6glhScxjuT 4XLw== X-Forwarded-Encrypted: i=1; AHgh+RqMmN1G/MvtpLi6nXOZYVJqtdtUL3MGnVjpXyu8g4HqdN45VE5WpYm4SlpZTMvNryp1hcoarE2fAmY=@vger.kernel.org X-Gm-Message-State: AOJu0YwsqOmMwihfZmNqdLle/4qHj8oSo2OtsxMYalxYJl2EOkOj1dVh IXwJTXwtjcA7WF2SNurv9/B04HfoERytDBPK0xib5y/RM6HtKIhn7E9iHiFOZ2bbmQ3fCrZ8PGE o2u3Dww== 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: linux-doc@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.