From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 D412231A567 for ; Wed, 27 May 2026 15:38:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779896323; cv=none; b=GLkdNeQbhhh/GvfCojkTU64dGku7AOuwKxEg1hghJ6Ft/ovW6+PjNu90P4E0dx5ZLTvuo1WRqau4VAv4TRJo5nscJU5vp8rPyBorowybaQeqGNiswMGtsgQe6SDGs9q8VhqPhrZGtjQoCnuYj+KwjAbElOI93NdNMQedE16KIaQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779896323; c=relaxed/simple; bh=AiSCf2SvzEfO/M5UoN7hNf2bZmPUZiogKQ7yU8QLODc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hIwhSdGSM/EG8x7C+sTKyIVmqraVY0y57g2g4cedoFEmOsNo8QL388wu4EngBDG7OVkmeicOJyg8oAxFwwevkWJlQO5uCnc/AVxiZJP/EvnlG7FPamUg2n8JTdcvbLJVfR4Kpx9rcS+sMNTbDLFDkupCd86n+xBpgRSKyT/1DWc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=DDOgUmu5; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="DDOgUmu5" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-48d146705b4so125775695e9.3 for ; Wed, 27 May 2026 08:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779896319; x=1780501119; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=N+0sHly1saG74fNtjoFtR54rOi6m8O/A/iPVNFJy9CE=; b=DDOgUmu5HdJb7kXDAsLcBz67fyGYIgdkIs6GoWHD/ZZ9gzbGSsx89W+dqJe1Wsi9/k qz6ZXizw5/THK7iGoRzvmpac8apSZmSTA1iduYkd/vAoe5JWyy09wAVrm50ntUTlYh0u VPTS6pT94pi+f13QGvLDLpNGzXDxYmUIBEaPOGKkd7mKRH8Mh9f0d4EQakkRs07bNxft 2JQswlxdx+mdeOnCwOnxhYnoqiGLMlNlq3r1jPshcCkVUr2PDalWtEacz7lHbK7ejWsL x5B7aEgam4KkkZnxa3NVIDx/8f5HQ6nv44tKJgWeZEbYs5xsq8KljvXbAThC+AYwQC5X /rsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779896319; x=1780501119; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=N+0sHly1saG74fNtjoFtR54rOi6m8O/A/iPVNFJy9CE=; b=ctGFbKif/BhYAhGJSmhcPZBYywSa9IEphebq7WFWOS4cDXVyvUr+FsVpCBbE8Uveia Oa2IUtyARXkBFYL6J5QfUQ6ULWY0Xc0lcoLXjI3mv/iotilYe5zhSzd7vs17L2AFui8B qgU3SXzpOg/JVBGrN1TfiTrvE1mQW5YmjLEA6OGdEx4/5HRbklBmGGxLgMXXDHSHQtOL 2WfzgV11r1rQTEsiKh1+S479dDtuBuMnu7wyT/vDSi5FzXaJ8N9PYo37tPAmgOQ7Ehrb 281G4G4MMSBPzT8EVIB3VSZ8KqTD1slRmWvLHc7dD7RTcldm7JqN6+5YjD1OniATZZj4 fKsA== X-Forwarded-Encrypted: i=1; AFNElJ/WHYKHDjHMH/B4qbGtSur/AZgUvX55EDyVDD673uK5t2s7xyCiA0bkJbz2DipAD1+cAJy3Va5Ccqqgmk8=@vger.kernel.org X-Gm-Message-State: AOJu0YxvGugAsI+QZ/doSQFrSdP2KiUbbfAWEKHUcb6ybfePgCUjx/RF cxuBSrTiKU6+XVbitAGebhShC7myLkQl9D1hX7MS/K0QkSA/L//djreqNVj1Z19DSJSM0cefEHR W+SOx X-Gm-Gg: Acq92OH+aBjTtpzCj7xqiKlxBw+xs1ljCK4QGkoUaK+pR3tQRqijC+3ty4A77olnp7i 0hFig/LFAi3A9HNdxdCVfTO5H2LLJfPS7EHNWJoqjFSTjbQxHZI2IvCG37FdyVedsvcv3jH1plW vxkRQ0QH6G5Q56dQUT/MCDmwmFa4KwDOLRsnNQYaSbyXc0saEXNIFtm6I1F8YswBe3ldoNwSkTh oh2zSZAswkcn/RrKu+W3XmejCyO2dGT9IIKF4gdaSZgv9ACoM+40QIJi4YiN0lcjT3SUtow7/Ym SLx2UtJJi5eERcyZ9IVaLa3YSJu29y44ys6Jreac+UTVmyDlAnkwz6jRHKKJc4RrI0rjQGDE/oR QHTaH91zZRoR1LEg35+Sb8R1CaQXkN1kvwtdlaaGfJi2wN3c1tFvFWt9+rwd7U/oShREOWU1ksk D6KztS2RmMwuVINDHfIT0cL5rnsyHtqHImZsnmEba8 X-Received: by 2002:a05:600c:4e0c:b0:489:1a63:509c with SMTP id 5b1f17b1804b1-490422608cemr411908915e9.0.1779896319205; Wed, 27 May 2026 08:38:39 -0700 (PDT) Received: from pathway.suse.cz (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4908098cc6esm27933655e9.4.2026.05.27.08.38.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 08:38:38 -0700 (PDT) Date: Wed, 27 May 2026 17:38:36 +0200 From: Petr Mladek To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Andrew Morton , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Sebastian Andrzej Siewior , Clark Williams , Kees Cook , linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH v3 3/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Message-ID: References: <20260520-restricted-pointers-final-v3-0-76bca6a6ab3f@linutronix.de> <20260520-restricted-pointers-final-v3-3-76bca6a6ab3f@linutronix.de> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260520-restricted-pointers-final-v3-3-76bca6a6ab3f@linutronix.de> On Wed 2026-05-20 10:40:02, Thomas Weißschuh wrote: > Depending on the system configuration, the restricted pointer formatting > might call into the security subsystem which takes spinlocks, which > might sleep under PREEMPT_RT. As %pK is intended to be only used from > read handlers of virtual files, which always run in task context, > this should not be a problem in practice. > However, developers have used %pK before from atomic context without > realizing this restriction. While all existing user of %pK through > printk() have been removed, new ones might be reintroduced accidentally > in the future. > > Add a lockdep annotation to unconditionally introduce a fake spinlock in > restricted_pointer(), so lockdep can detect misuse even if the current > test system configuration would not exhibit the issue. > > Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ > Link: https://lore.kernel.org/lkml/20241217142032.55793-1-acarmina@redhat.com/ > Signed-off-by: Thomas Weißschuh > --- > lib/vsprintf.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index 9f359b31c8d1..021db95087fe 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -29,6 +29,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -862,6 +863,14 @@ static noinline_for_stack > char *restricted_pointer(char *buf, char *end, const void *ptr, > struct printf_spec spec) > { > + /* > + * has_capability_noaudit() may use spinlocks. > + * Make sure %pK is only used from valid contexts. > + */ > + static DEFINE_WAIT_ASSERT_MAP(vsprintf_restricted_pointer_map, LD_WAIT_CONFIG); > + > + guard(lock_map_acquire)(&vsprintf_restricted_pointer_map); Here is Sashiko AI review from https://sashiko.dev/#/patchset/20260520-restricted-pointers-final-v3-0-76bca6a6ab3f%40linutronix.de Will this single global lockdep map create false dependencies and inconsistent IRQ usage splats? Because lock_map_acquire() acquires the fake lock with trylock=0, lockdep fully tracks it in the dependency graph. Since this is a single global static map, it acts as a central bottleneck: every lock held by any caller of %pK forms a forward dependency to the fake lock, and the fake lock forms a forward dependency to any lock acquired inside %pK. This artificially links completely independent locking contexts across the kernel, which might generate massive false-positive circular deadlock warnings. Furthermore, if %pK is evaluated in an IRQ context, the lock map is marked USED_IN_HARDIRQ. If it is later evaluated in a process context with IRQs enabled, the map is marked ENABLED_HARDIRQ. Won't lockdep immediately trigger an inconsistent IRQ usage splat upon detecting both states? While using trylock=1 (like lock_map_acquire_try()) might seem like a way around this, lockdep's check_wait_context() explicitly bypasses wait-context validation when trylock=1. This would defeat the purpose of this patch. Is there a different mechanism to assert the wait context without fully tracking it in the lock dependency graph? My opinion: The fear of generating massive false-positive cirular locks does not fit here. It is the opposite. This fake lock represents the various locks which might be taken by has_capability_noaudit() on purpose. And %pK formatting must never be used under these locks because it might create deadlock otherwise. The fear of inconsistent IRQ usage reports makes some sense. It might happen and it might be confusing because %pK fomatting must not be used in IRQ context at all. The misleading IRQ reports should be prevented by adding the lockdep_assert(in_task) later in this patch set. Resume: This patch looks good to me: Reviewed-by: Petr Mladek > switch (kptr_restrict) { > case 0: > /* Handle as %p, hash and do _not_ leak addresses. */ Best Regards, Petr