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 A8DA0134CF for ; Fri, 17 Apr 2026 02:34:07 +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=1776393247; cv=none; b=IlXYiD03X+Fh/jepX3JpOPpGk1tByKUxQoX7KMojAu2Bu3xjzXNSA3ZwWSyoXrexmZtgMD1pbM4O+9MZli5f59qM3wrxfJKRIJHutW7OdxYczVND4+BZ7e61ex8wnO/d3eNXOmcOIZTf5y2h2qm87zjvKn1H9IeFlqlga/+SA1E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776393247; c=relaxed/simple; bh=ygdv9g47ic9ApuOFDxBT5md9T4W1LAkYk/F9rQTlLT4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=g6yg9dvO5+Ovf04Q4IfJhwPikWGMo1VJFVuqzPOQ+IVpFuFantnqa6lxRY6EwG4092KDrDyhxcXKDjKKhoBQGf+VPvjKjHFcwVTG1N/pDfRo9eNBMKzS2UA0hCg6NZ20cPNBCE2gy94YNmJGA3UHiXkaog9DXj6/75A4XUXA53g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E5Ln9W9Q; 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="E5Ln9W9Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1B72C2BCAF; Fri, 17 Apr 2026 02:34:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776393247; bh=ygdv9g47ic9ApuOFDxBT5md9T4W1LAkYk/F9rQTlLT4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E5Ln9W9QE/J8EGYSL8qbYK9166EkbeNdXxjBB6QlRraHZfNZYjslaDk7b+7bo1ZvI cjXIF0KblE5nOyIZGWwcIVwDOk5R/zul41ENTc2xRJKm9DnnJ3Enf7OtMIkTPx8keX 9P+EX8+x2GGnYiQQG4WD+nVqxHInHjVb/m7iRsBukR17nKdQQI67Oc8BfTmVQYxF5m xO3gCjmMxJ2+0eRdw2jNlI09ANxXUxiVxYLKuGANxTMxfmSN+yd6PakQT1VOARwLGo zP1zfM+Y1A3Ke0asKnHeopHGrUPQ5m0gE4JgWd2RdjqZ1OYX4vB4eY5d9cI1gebuxl 979LDkPy16BdQ== Date: Fri, 17 Apr 2026 11:34:05 +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: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; > > This one. 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. > > But it doesn't cover the case where kprobe hooks an arbitrary function > > (in the middle of kmalloc() or kfree()) and calls kmalloc_nolock()? > > > > > Yeah. Totally fine with that. > > > > So I'm confused exactly what you're fine with. Did you mean this? > > > > if (!IS_ENABLED(CONFIG_SMP) || > > (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))) > > return NULL; > > Doesn't need to be that drastic. -- Cheers, Harry / Hyeonggon