From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 7CB7D35F18E for ; Fri, 17 Apr 2026 03:59:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776398390; cv=none; b=O4qdB4Eh0l3K1hhHKyB0Eufdra4n56xYrukI0gOoPNj+OaZK1+jn0/cXb6PULtwOUWa9IlLssXtFzKRSdA1EEjec72Ox4tIzYTUVmnENVMRfIYBCTR5Kmti9ADhjBunLrOPhu5ZDEbrMCUB/jLsgXwQPw0oMXCHZIEg4xT5+Rr8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776398390; c=relaxed/simple; bh=FYMWlIv0R7SHlUNfyCiW5pjJHyGqG8EslRD+hgoM2sA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X8vvnEcAm7Z61luN0TUZ90uwsO3sfZAeLdEiC6XC70yyxPjZEhkfqzi5Sfw1QJ5uWaMnRAFTm5dEb7iAl1QfFmvvyeo5KiDoBAaLizh1KXgCmVLcJN2XN2kVLW88ty0rKlAqUdTGLAnNB8+xNqYKcmczDrd6Vfgmr6uftkLj4Jc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R7U3ZsGr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R7U3ZsGr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1036C19425; Fri, 17 Apr 2026 03:59:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776398390; bh=FYMWlIv0R7SHlUNfyCiW5pjJHyGqG8EslRD+hgoM2sA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R7U3ZsGrLgMgL9Zyy2JM07b0SVO5tpzNJkedWlWBu9Z4GH2l8UAehB8ePUw4lJxIV ER8BrbhAkcLTYJifxrWDW8GMrj4T+T7C+Hi97jlgfJLYEQ+tQWKTCyU5LcqXxccEVs DXcLeJ5WWuAvOMCFtYcv8lBvz1a+XFBhUx3Krv80oehO2MzmrlIPXzfKtQVf0Tbfqb fnIJBR0vnOSQojETGU0HJa4/Rft0VHv3USIkkhAkj+lfEb9GEsre8+tXmXBsemhhwJ DMfcIbPRB26gAU53LS/qocRQ/IllNnKNnh/FHGZEUQXk9ebz4A4sqUK9rv88ouTt3g x51MvSMwedFIw== Date: Fri, 17 Apr 2026 12:59:47 +0900 From: "Harry Yoo (Oracle)" To: Alexei Starovoitov Cc: "Vlastimil Babka (SUSE)" , Matthew Wilcox , Vlastimil Babka , Peter Zijlstra , Ingo Molnar , Will Deacon , Sebastian Andrzej Siewior , LKML , "linux-mm@kvack.org" , Linus Torvalds , Waiman Long , Mel Gorman , Steven Rostedt , Hao Li , Andrew Morton , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , Christoph Lameter , David Rientjes , Roman Gushchin Subject: Re: [RFC] making nested spin_trylock() work on UP? Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Apr 16, 2026 at 07:41:02PM -0700, Alexei Starovoitov wrote: > On Thu, Apr 16, 2026 at 7:34 PM Harry Yoo (Oracle) wrote: > > > > On Thu, Apr 16, 2026 at 07:37:49AM -0700, Alexei Starovoitov wrote: > > > On Thu, Apr 16, 2026 at 7:35 AM Harry Yoo (Oracle) wrote: > > > > > > > > On Thu, Apr 16, 2026 at 07:26:36AM -0700, Alexei Starovoitov wrote: > > > > > On Thu Apr 16, 2026 at 3:05 AM PDT, Vlastimil Babka (SUSE) wrote: > > > > > >> I think we need a special spinlock type that wraps something like this > > > > > >> and use them when spinlocks can be trylock'd in an unknown context: > > > > > >> pcp lock, zone lock, per-node partial slab list lock, > > > > > >> per-node barn lock, etc. > > > > > > > > > > > > Soudns like a lot of hassle for a niche config (SMP=n) where nobody would > > > > > > use e.g. bpf tracing anyway. We already have this in kmalloc_nolock(): > > > > > > > > > > > > /* > > > > > > * See the comment for the same check in > > > > > > * alloc_frozen_pages_nolock_noprof() > > > > > > */ > > > > > > if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq())) > > > > > > return NULL; > > > > > > > > > > > > It would be trivial to extend this to !SMP. However it wouldn't cover the > > > > > > kprobe context. Any idea Alexei? > > > > > > > > I think Vlastimil meant it'd be trivial to do: > > > > > > > > if ((IS_ENABLED(CONFIG_PREEMPT_RT) || !IS_ENABLED(CONFIG_SMP)) > > > > && (in_nmi() || in_hardirq())) > > > > return NULL; Just realized that it's unnecessarily restrictive to disallow hardirq context on UP. Tried below and it resolves the issue. diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 2d4b6f1a554e..777499f814f6 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7798,6 +7798,11 @@ struct page *alloc_frozen_pages_nolock_noprof(gfp_t gfp_flags, int nid, unsigned */ if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq())) return NULL; + + /* On UP, spin_trylock() always succeeds even when it is locked */ + if (!IS_ENABLED(CONFIG_SMP) && in_nmi()) + return NULL; + if (!pcp_allowed_order(order)) return NULL; diff --git a/mm/slub.c b/mm/slub.c index 2b2d33cc735c..522a0a0d7bcf 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -5304,6 +5304,9 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node) if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq())) return NULL; + if (!IS_ENABLED(CONFIG_SMP) && in_nmi()) + return NULL; + retry: if (unlikely(size > KMALLOC_MAX_CACHE_SIZE)) return NULL; > > > > Thanks for clarifying. You mean not covering the kprobe context is fine. > > > > But I have to ask; how is that fine? Wouldn't this leave a small > > possibility for a kmalloc_nolock() caller to trigger > > e.g.) use-after-free bug even without noticing? (yeah, very unlikely > > for somebody to trigger in practice, but not impossible) > > > > If it's unlikely to use bpf tracing on UP anyway, it'd be safer to just > > disallow that to happen to begin with. > > Don't fix what is not broken :) Ack. > I'm sure there are millions of other issues with UP, > so there is little to zero chance that anyone can repro such a scenario. *wishes people running UP tests their kernel with DEBUG_SPINLOCK* -- Cheers, Harry / Hyeonggon