From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A071C212554 for ; Wed, 20 May 2026 03:16:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779246975; cv=none; b=a6lEP5Dy3fcPszbGJvXqFrl8GVyMo73ZDkS+sHSiBCMa/ZycVRQUITiAQ7r2n9ibqPGeIz/C3kPfAMURxrq3eCNwRo6hq0WRPpO37l2dIIeM0eFqFmX75d67A4Jv+7tfMKgsJpLQZZ5Bb9OC/pl5UCfHhw+jrQ/yvqe7+ZMZWts= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779246975; c=relaxed/simple; bh=o2s6BaKkTQV1idTWQHTacwAJ06v4lLZBwtO+zckuYQg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qYDVtslNne3E/+dQaAy90Z493EkpcLPLJZKc8Fxv0izoAIZRHLcid7Qs5Yf9pOoiAjseNlswNzQBpDHBZjCbFkkJYvLkVtzwWBXjdnYwfpykkI84f2+7hyxO8GyWKQ8S/0/IKjuKCO0inZyot0LHbB0R1REcwxYGhQ3U3Vs1Ssw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YkbVnLYP; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YkbVnLYP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 383121F000E9; Wed, 20 May 2026 03:16:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779246974; bh=8M808h6POUPjBABuK+39vGP5JIHi2QH7gbVYftWgWEg=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=YkbVnLYPif2yCNMuLe+yYMLGdMHNQfRE5Q1tawbNRYYjve0pCPvdRikC2Qg93FY0Q lkuVVMyvWpL0kvj3U61HPJwtOTQl13LwQHaQDoMuqGOH1uFXAoOrAycOCF5Nr3oUtJ 1OaqbJXhcIlKKIdlf+Xm6Y+eb3EApmYWZSPLwdcroSf8EZgQTKSgILdle+LA7aYJJi BCYIfN39W8BMjS/n84Px346eBY+xy/tDIo+ZcZJPeilA7ZKgL91X+ykIV/bj1S92wi xE3Tz/quErHzJonjQhcZyPXytEKpLrExyVMTGh5ZV04lVDnGRoVvpRN1L04lp5I9TL IVUua0JvdcxcQ== Message-ID: <6c089de3-34d9-4dd9-9646-f51328c77497@kernel.org> Date: Wed, 20 May 2026 12:16:10 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/page_alloc: document that alloc_pages_nolock() uses RCU To: Brendan Jackman , Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Zi Yan Cc: Alexei Starovoitov , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260519-nolock-rcu-comment-v1-1-4a630c8794e5@google.com> Content-Language: en-US From: Harry Yoo In-Reply-To: <20260519-nolock-rcu-comment-v1-1-4a630c8794e5@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/19/26 11:17 PM, Brendan Jackman wrote: > 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. What prevents an NMI from triggering when RCU isn't watching? Oh, wait. an NMI causes RCU to start watching! > But, expecting readers to make that > connection for themselves seems a bit cruel Agreed. > (I don't think there is even> any documentation of what noinstr means at all, let alone the connection > with RCU). *flips through the documentation* Oh, perhaps Documentation/core-api/entry.rst? > 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 The email should be junaids@google.com, not jackmanb@google.com? ;) > Signed-off-by: Brendan Jackman > --- Otherwise LGTM! Acked-by: Harry Yoo (Oracle) -- Cheers, Harry / Hyeonggon