From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 975303B8953 for ; Wed, 18 Mar 2026 11:01:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773831682; cv=none; b=Rb7T4TfgCN/p63U6lLjJ77HoXp0ae3FnhtNDBJFSl8EwsA+jHEwh6p3B52KHIIEgP35jsFdMwX0NjG7xQ8BOs3XtbPO927bKurDDcILUcth8Qn+R3yWNxkRazPHPgENkILXn8/ynBK1w2ekgEOSyL2E5RS0yFT6UkVLwWpFabbA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773831682; c=relaxed/simple; bh=ceh/vaMTbBxe3gEJSesDynGHtSsV/EA0AtK1Qm64kg4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=F5pJoh6b6rvxbQzqd/8H+Ia+on3do8qDTEsSby0+wQmE4cmw2V4vS4w+sV9YvtCK+1LWqe15X4UwaGQt0ldsQgXL1cQMMCov/K1noYBUo34t+pDwz0XJu7Dli2FsTHpH/VsmYr+msECMdcS/aZNPbyBDUIVMFaLUHcZTIrJLGLA= 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=L6Fjk7TP; arc=none smtp.client-ip=209.85.128.53 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="L6Fjk7TP" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-48557c8ad47so43595055e9.0 for ; Wed, 18 Mar 2026 04:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773831678; x=1774436478; 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=6x5/MsAHJgdsEtzGcdIhlzBB2KVlhmQvmu+8tRtW+U4=; b=L6Fjk7TPAaRfU4iT3T2Ux0IZYgK5w+3YZXjVUz/jAPvK8RV7q478ciS0ahoOrat65y KkGpOeOYt2gm32gwsKZoJNsVhYGXol7JV/qiKh6MYvbKgvhhl/kPtqlTPWx4aKHVW3Cq aC1juSrWh245qvuwaY/EkB5xFRoLedD13HGF7hSzBvGFwQ9jw9xD0zu985GFTZl54x7V QxFeZQ95rgwqXhlE979Ul2RQhGNWIFMgzOEHYg5zH62vW2T7nk8/rq7YeUJ6PW+52GW/ mXdQ54526BpIfS+GjXZ1lKoLngFQAfn5liwYaeqO08DJs5Bx6PdaMpjdhMxZySbOx1IZ fpVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773831678; x=1774436478; 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=6x5/MsAHJgdsEtzGcdIhlzBB2KVlhmQvmu+8tRtW+U4=; b=IFL8MmdAv/U546xb0ze2d4HlPNAf9Nz8zPDtFtRSsW2ISHVI0B3nxmfyIXAVNDECEB od/b2rEkXcBALJNwLc8848quacdiYjb3MkoYWm/d5DLn+3EmXcd/kW0U3nEOw1+WyFqE oM6OYmcPRI82bVnvT0labVIBdUnAPjjI7kxLWrBAyOG0OjS88OBCJCvqxKw04RwIvNbR oLDPqBGNMCe1APzE3WBOMHhZVujtEazt4AJu69gXBpc7cFK0B0KabF86NF2R5WbmdTjc MbHrHpAdzGlmK/L0U3+Ob3YJIk+pNu4dtJCLLTmzUmD/pQ6WG4zumYjf1hUBo3rAOtTQ CyoQ== X-Forwarded-Encrypted: i=1; AJvYcCXvT7h+fIPj5ohtL++EfpRuEfUPp0tD7a4G5BJZDPNFbbLzYJnkMj9z3Yy9G08yjdoBw7uryKlBnnyjasc=@vger.kernel.org X-Gm-Message-State: AOJu0YxMBrFpmXhdPPfsQXxwM5LvlfK9Ec5j8LYIqg6RdnQ9gtyOlExS xvkLYsfgUcQAvgd4uBfg1xSJb96oSYQ3HwRlmjBfETy/yorM1M47JVgnW4K6coEBYno= X-Gm-Gg: ATEYQzzT8ERAqrQtK7Xm4KwaDZPKzX88TEGX799WMk1SLSukoCRYNhjeq67kmwntaXd ANnj7XRhOJuGQ0K6tRbjLZadQxLqXejE5YEakF7pTKJIsvtklpBtR/6CzDP7C1YZc/y7UhxyIgK FHVVU8DRJx5EMnZWyMlY0s0nf5p/oaWDtkgJeunAbxCcmBuKefr9zFPnuI2wrwxT8M2KJPeFXZY 04PlEPouirVhvsPqP7cBHudvzE3N/aphiIa4DNv3YuGl3oUBaeato7+7fPhh9+t8JR2bVdE6GVg vPFfEEEwtcItGFwyUs0VEfLR/aMUQcetUodB2XjmRddS4NKbEd+3r49Mw2xuw6lCAVs6Sy2Peao O5S2r+EB2tLBwhWh86UgiZzVzMPlTKumlYTpFH+pTKKQFEpiQvRhEw3Gz9vlUQMnvzK2yjvxa1n Cd6lpDjY/0XELe5QTgP9dTwfS3PA== X-Received: by 2002:a05:600c:358e:b0:485:40a6:442e with SMTP id 5b1f17b1804b1-486f41ff20dmr57697415e9.0.1773831677478; Wed, 18 Mar 2026 04:01:17 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486f420d946sm56203565e9.1.2026.03.18.04.01.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 04:01:17 -0700 (PDT) Date: Wed, 18 Mar 2026 12:01:15 +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 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> Added John and Sebastian into 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