From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 9AFBD3A1CFE for ; Wed, 18 Mar 2026 11:03:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773831827; cv=none; b=YtF4bxIktta+X1S1XXl2nGhbasXD7yZGTT0PXGeJTtFdLuvqMd/enfK994gmqSpJHpN41We+P94ocHmikfwoyu1rIRERWxpBwRiNNJOqdAp2kxC7sJGDyrcTTIAln6xMhfNZ+dgw0hCHYrEjgVJaqG+obQNd1E/wEpGr7wx/rfY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773831827; c=relaxed/simple; bh=l5YzJS9neVzwQIQIodMhvQ533SDUoqWPU1Y4H+/Tb9c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FsbF63znWkSlBvfeSlKcNd6hzGkZaUTPcMHmFs6SMpQF6Lk7O0qK/7GBpm+lP+awnp+RDxFJebU9SbrtzmMKutLbKD8DXkK3hVPkWZlCEpqVIqpc8rWMSLDWEWj1EuPdXHy69iAxuydB8I4f7szlxCmK5GwqkMxJTIV6esDeCJE= 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=AQF03eb0; arc=none smtp.client-ip=209.85.221.54 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="AQF03eb0" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-43b48ac2727so1955412f8f.3 for ; Wed, 18 Mar 2026 04:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773831822; x=1774436622; 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=mqbmQpPDzNxd+9U2zkjukOSM/XlzqHrosKoQR8DcpOI=; b=AQF03eb0Rn2uRO6lsYT0prbgoHT9Z5t5ftv6F922V8qZXZXPRvPJa1TNge6Ndk/gur 7TdYfLLO7KYMS2m3Q8QclPSK6bureMAKgrT6O/igfNNWf0l06TXtP/4lD8nuiZyyqccT VJyrCYllfBXcqSdK1g/nytVQDojvYPdc8ot4qjySqn3dzVXpHHTaulwi3bUK76s71Xg6 LfK1P/NOOjB54danD0tsaIM11gDuJdpBe/0VXYVXlpLL1mVVFSfiy9HwuLN+TntflsA5 kK554pzFuMRTKQYflvge73HM+4w4Tt3T29l2ssxfhuIs1TfE60fsIdMT2jkhmV0KOe3C hFcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773831822; x=1774436622; 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=mqbmQpPDzNxd+9U2zkjukOSM/XlzqHrosKoQR8DcpOI=; b=WRXYEFRZadDaexs62OV0A0wVNCghvHdGY8z7dL3wwcboJIHEtnGkcL2gWR9pZJKijs fvyZg6Gnpl4bv5rLUAaEoqpcK0yJN4dDg/Od1OGk5DwM0PzEnD71YYaen4RWv/0XoPLk 7CxdwT2JNHh97C/uDy0egDP3Hfj6WjWwB0h4drJ3vOqPW4DETJtRJOXy4HyI1vAMsi1O DUY1aB2dqvt9QreDJrHpmVP7iFBxRTiUEMW6BunDfgyGCspswjHqGPsDaIThtE3R/q3h 4/rNsn3XLektgwpbvXlaBaqjvu7c6a7Lzmo3P8T/7gcnp4YIrWMHhz218gRIniGnx8w9 OfNA== X-Forwarded-Encrypted: i=1; AJvYcCXPeU3ZdMH92LXfk1s+4/ia6pw2ccZ1cmAT7YxqIykWtq4OXSaLvkJxGm7dGl4KxNJLGx6D+kD6pGPysto=@vger.kernel.org X-Gm-Message-State: AOJu0Yz6YTjw6zvhNYXLB8idI+MCu/DBY+MvzRpzkpjBL6snYuYOWRrX dRoPazm0RtbqkhCerE7T+3TtCcux/VXwbObpOhcAz3P/DEYJLE+Ar4HMSsQu5LC2h2Y= X-Gm-Gg: ATEYQzzSyCcN0xos1AqvbXVBxZoy8boH4+5GrtDmo1dnLEsym9Sk7ExyNaIhkJyzlDx Dutr+LJ4LDYdo9tM9hmaIND7VG5NrZ2Hu4zqOTpsr+XvCDv73NmRwQSMs3GHG809HLOQttP5ok0 +XS06XNDDx2c2Dl6xltDRTkjnosAi3ncXvntUbmCmCexwGa4xl6ulalhLOmoU7+bBRnEX0ivbD7 KYwZr/nRrQKMKZbcstw+XpuYwR+HGjqGY5/PmEzxa7Km9I4xWKLGhZng+C95fUB+cqgDsZsvxT6 fVjFlYawcP0Xh5RPU2cTJohy21b0v1NbcJBZg3pp01j9GGPKstjs5v27LdKUarCnOHt/mKzWcwO siqhoNR0/Kh7EEexfXez1UZCwf1jHfSzWVuvqEDer10VUqABkefgascViW9vHR9L0Kl39CqaD/i l9szMdQJeQtp962Tcney+uYQeYGw== X-Received: by 2002:a5d:5d02:0:b0:43b:4f86:e996 with SMTP id ffacd0b85a97d-43b527c3ca5mr4680489f8f.29.1773831821592; Wed, 18 Mar 2026 04:03:41 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b5184957bsm7474683f8f.5.2026.03.18.04.03.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 04:03:41 -0700 (PDT) Date: Wed, 18 Mar 2026 12:03:39 +0100 From: Petr Mladek To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Andrew Morton , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , linux-kernel@vger.kernel.org, John Ogness , Sebastian Andrzej Siewior Subject: Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting Message-ID: References: <20260317-restricted-pointers-final-v1-1-b4dca0ed6483@linutronix.de> <20260318094555-37b1a6ce-4977-4e54-95f2-2a30bec904e1@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: <20260318094555-37b1a6ce-4977-4e54-95f2-2a30bec904e1@linutronix.de> Now, really with John and Sebastian in Cc. On Wed 2026-03-18 09:48:06, Thomas Weißschuh wrote: > On Tue, Mar 17, 2026 at 12:41:23PM +0100, Thomas Weißschuh wrote: > > Depending on the system configuration, the restricted pointer formatting > > might call into the security subsystem which might sleep. > > As %pK is intended to be only used from read handlers of virtual files, > > which always run in task context, this should never happen 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 might_sleep(), so that misuse of %pK from atomic context is > > detected right away. > > > > 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 > > --- > > This depends on commit 5886cc8f895b ("drm/msm/dpu: Don't use %pK through > > printk (again)"), which was merged in v7.0-rc2. > > --- > > lib/vsprintf.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > > index 800b8ac49f53..eb9dbb28fb9b 100644 > > --- a/lib/vsprintf.c > > +++ b/lib/vsprintf.c > > @@ -862,6 +862,9 @@ static noinline_for_stack > > char *restricted_pointer(char *buf, char *end, const void *ptr, > > struct printf_spec spec) > > { > > + /* Only usable from task context, The call to has_capability_noaudit() might sleep. */ > > + might_sleep(); > > + > > So might_sleep() is not actually the right thing to do here. > Some callers use %pK under a spinlock, which fails the might_sleep() check. > However this is fine to do, as has_capability_noaudit() also only takes a > spinlock. My understanding is that we want to simulate that we are going to call a normal spin_lock() which might sleep in PREEMPT_RT. So that we trigger the warning when %pK is used under a raw_spin_lock. It might likely be achieved by adding a "fake" spin_lock and might_lock(). I am not sure if there is an easier way by using just a struct lockdep_map. I am always a bit confused by the lockdep annotation. > > > switch (kptr_restrict) { > > case 0: > > /* Handle as %p, hash and do _not_ leak addresses. */ Best Regards, Petr