From nobody Mon May 25 02:53:40 2026 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (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 C2EC64E3786 for ; Tue, 19 May 2026 14:18:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779200287; cv=none; b=FqC4wvYaIgQs9Tmt4el3FDS2jwfFTiKX+VgYH/PLT6iWLO5AffqI4Q0efjqK5lIKlkVuyG53GVNaV4/EqwBz+iBvdEm1aNcnC4GgyCXt3sIKUV+5rHg6r20FgGOMSNXl2PG7NtimtM5EPeCg//QCLqeuQ7rPy+XJerzN7al0SZA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779200287; c=relaxed/simple; bh=NVrAh/90W7FcanSv4pHaStwMXa5hAAMYBkMucXij1V4=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=i8tOJlkAMgtMIIFbOFB9g8Ic8SXihXRr3H/FoKY9Te89q2eGUtuWC2R3sUj7JqSBpq1eVdzJmXYOlVhjM7EjVSXupMATeBxbdhgcB5CM7wEOU0dxFwp3thmOzoqGrkQOCqXTDJVvMZmwdFnj5v/DWuqxrhAJ21MQ0w9xjrcU4Bo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=OKPZFH6m; arc=none smtp.client-ip=209.85.128.73 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--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="OKPZFH6m" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-48fd64c32e8so24798345e9.3 for ; Tue, 19 May 2026 07:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779200284; x=1779805084; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=uems65kP0VRu6i+029j484GD21MKk/86CTpEq9XOK2U=; b=OKPZFH6m15Bevo5jeLOubhGd6fIV6GqN/s/HeABlWepZp5F0rhpTlE2PbMHizPRaGk IAhsV4bCEVH2XgRwPrn9f7FocMYj5WTT6mV4Aa7FfGPLAt5EwZOJtrkQzD7BFOgoiWQu vM1aB6uh8jIKdAUQcY8+yTNzPra94W1d6N/8Bpus8lBGQqVNztwwI/hxliSrdbYRlSlU BPzbpHfiBM9mPQTCEYrsUi4ciQ2d+X9GwG2Ij3gGZbRKdQUDnn+NkFPObQeXARyXa63i vqQsgEip+O/jdWYb9vyuOqA6V26Y6YfkCNNKOosjZZqPZWenlBjR/2fpeIyXcDe/aAet FGZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779200284; x=1779805084; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uems65kP0VRu6i+029j484GD21MKk/86CTpEq9XOK2U=; b=bRJcJ/TtqQEN8XH00SnFfE6oyAtgDri+xk301NKW7HSETFmVgOxZezZ2mp0MvHbPaV dgNFFLEOUxI9GK+6RiIscUIsatFpN4jAWp1YTdvmyjefg2ELTvdWObn5jaO8sXkLWgqV 9tQqlGAxW8nd0kFk+SLaX0csKoQju2TmUJx7KNMytP5HMAmwVd6497rxhxM3RNYDPVd7 C3ptHTuDRJPd75yEO43WUgVbB1PXImg55AV0m3FqSnJ7j3XDvGtDqV8f5O/AaLr5EeCW lsZoJQcMsFNTx9CnUsBDNkpgSMxWDD5a6mpj2pRzlL3z2MQpOS4Rj/4ZHeJ/T2cduUIN 8ocA== X-Forwarded-Encrypted: i=1; AFNElJ9bnh0rxtFo+tv++S9WOsX6lcwp2owJzt5qHYh9S+CcxC1AKPwhqzQOVygpTzoHJG56EkUE0v5c2FkAyRc=@vger.kernel.org X-Gm-Message-State: AOJu0YwgoriCTs+bIByQnoLG3zbYokuiH2xMVw0s4Q4H+imXkaeuc4Vq DXvoRL3deZ7gIqvHBMVelHEauYgb0JMeDjkhwsa8FsLqFGGrNVw7kUDltVNvEE93niqyOfIpTjh yJ0XRrHb5F3RFeQ== X-Received: from wmbka5.prod.google.com ([2002:a05:600c:5845:b0:48f:e178:4b87]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:620d:b0:490:18cb:e820 with SMTP id 5b1f17b1804b1-49018cbf419mr73386035e9.21.1779200283971; Tue, 19 May 2026 07:18:03 -0700 (PDT) Date: Tue, 19 May 2026 14:17:58 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIABVxDGoC/x3MTQ5AMBBA4avIrE3iJ5pyFbGoMZiglRaRiLtrL L/Few8E9sIBmuQBz5cEcTYiTxOg2diJUYZoKLJCZVVeo3WrowU9nUhu29geqFmxIV32qtcQw93 zKPc/bbv3/QBYgvNoZAAAAA== X-Change-Id: 20260519-nolock-rcu-comment-8e6eac83b6b8 X-Mailer: b4 0.14.3 Message-ID: <20260519-nolock-rcu-comment-v1-1-4a630c8794e5@google.com> Subject: [PATCH] mm/page_alloc: document that alloc_pages_nolock() uses RCU From: Brendan Jackman To: Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan Cc: Alexei Starovoitov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Brendan Jackman Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The allocator interacts with cgroups which rely on RCU. RCU does not work everywhere, so the "any context" claim is slightly overstated here. This should already be enforced by objtool, since this function is not marked noinstr the x86 build should fail if you call it from a place where RCU is not watching. But, expecting readers to make that connection for themselves seems a bit cruel (I don't think there is even any documentation of what noinstr means at all, let alone the connection with RCU). Note this is not claiming that any cgroup code called from the allocator would actually break if this restriction was violated, it could very well be that there's no real way for the allocator to act on a cgroup that can disappear concurrently. But, since it's likely nobody has verified this one way or another, better to just be safe and declare that RCU is required. Allocating from an RCU-unsafe context seems a bit crazy anyway. Suggested-by: Junaid Shahid Signed-off-by: Brendan Jackman Acked-by: Harry Yoo (Oracle) --- mm/page_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e262d1316259d..7e647d047a2e3 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7938,8 +7938,8 @@ struct page *alloc_frozen_pages_nolock_noprof(gfp_t g= fp_flags, int nid, unsigned * @order: allocation order size * * Allocates pages of a given order from the given node. This is safe to - * call from any context (from atomic, NMI, and also reentrant - * allocator -> tracepoint -> alloc_pages_nolock_noprof). + * call from any context where RCU is watching (from atomic, NMI, and also + * reentrant allocator -> tracepoint -> alloc_pages_nolock_noprof). * Allocation is best effort and to be expected to fail easily so nobody s= hould * rely on the success. Failures are not reported via warn_alloc(). * See always fail conditions below. --- base-commit: 444fc9435e57157fcf30fc99aee44997f3458641 change-id: 20260519-nolock-rcu-comment-8e6eac83b6b8 Best regards, --=20 Brendan Jackman