[PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Thomas Weißschuh]

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 <thomas.weissschuh@linutronix.de>
---
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();
+
 	switch (kptr_restrict) {
 	case 0:
 		/* Handle as %p, hash and do _not_ leak addresses. */

---
base-commit: 2d1373e4246da3b58e1df058374ed6b101804e07
change-id: 20260107-restricted-pointers-final-cd24979fd752

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Andy Shevchenko]

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.

...

> +	/* Only usable from task context, The call to has_capability_noaudit() might sleep. */
> +	might_sleep();

Yeah, but for kptr_restrict != 1 it's not true. Perhaps might_sleep_if() ?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Thomas Weißschuh]

On Tue, Mar 17, 2026 at 04:07:56PM +0200, Andy Shevchenko 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.
> 
> ...
> 
> > +	/* Only usable from task context, The call to has_capability_noaudit() might sleep. */
> > +	might_sleep();
> 
> Yeah, but for kptr_restrict != 1 it's not true. Perhaps might_sleep_if() ?

kptr_restrict can change any time at runtime. The whole point of this patch
is to detect the API misuse independently from the system configuration.
Developers probably don't test against kptr_restrict == 1 and therefore
it will only blow up on users system.


Thomas

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Steven Rostedt]

On Tue, 17 Mar 2026 15:26:13 +0100
Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:

> >   
> > > +	/* Only usable from task context, The call to has_capability_noaudit() might sleep. */
> > > +	might_sleep();  
> > 
> > Yeah, but for kptr_restrict != 1 it's not true. Perhaps might_sleep_if() ?  
> 
> kptr_restrict can change any time at runtime. The whole point of this patch
> is to detect the API misuse independently from the system configuration.
> Developers probably don't test against kptr_restrict == 1 and therefore
> it will only blow up on users system.

Agreed. Those that add a printk with %pK in an atomic context may have
kprt_restrict == 0, and will not know they just added a potential bug.

We want it to warn if it is used in any problematic way, even if the
current settings do not trigger it.

Similarly, like we have lockdep in tracepoints:

include/linux/tracepoint.h:

	static inline void trace_##name(proto)				\
	{								\
		if (static_branch_unlikely(&__tracepoint_##name.key))	\
			__do_trace_##name(args);			\
		if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) {		\
			WARN_ONCE(!rcu_is_watching(),			\
				  "RCU not watching for tracepoint");	\
		}							\
	}

Where lockdep will warn if RCU isn't watching at the call site of the
tracepoint regardless if that tracepoint is enabled or not.

-- Steve

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Thomas Weißschuh]

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 <thomas.weissschuh@linutronix.de>
> ---
> 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.

>  	switch (kptr_restrict) {
>  	case 0:
>  		/* Handle as %p, hash and do _not_ leak addresses. */

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Petr Mladek]

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 <thomas.weissschuh@linutronix.de>
> > ---
> > 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

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Petr Mladek]

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 <thomas.weissschuh@linutronix.de>
> > ---
> > 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

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Sebastian Andrzej Siewior]

On 2026-03-18 12:03:39 [+0100], Petr Mladek wrote:
> 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 <thomas.weissschuh@linutronix.de>
> > > ---
> > > 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.

might_sleep() seems reasonable if any usage under spinlock_t can be
excluded. If the usage is intended to happen only from task context then
in_task() would make sense. This would already ban any softirq context
and everything else I know we had in the past.

The fake spinlock_t could be achieved by just something like
might_lock() which would avoid any overhead of real locking.

But do we still need %pK? There are far more %p users in seq_printf()
context as per
	git grep -E 'seq_printf.*%p\>'

than %pK. According to commit 312b4e226951f ("vsprintf: check real
user/group id for %pK") it is temporary as of 2013. There should be a
check at open time instead.

> > 
> > >  	switch (kptr_restrict) {
> > >  	case 0:
> > >  		/* Handle as %p, hash and do _not_ leak addresses. */
> 
> Best Regards,
> Petr

Sebastian

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Thomas Weißschuh]

On Wed, Mar 18, 2026 at 02:59:36PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-03-18 12:03:39 [+0100], Petr Mladek wrote:
> > 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 <thomas.weissschuh@linutronix.de>
> > > > ---
> > > > 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.
> 
> might_sleep() seems reasonable if any usage under spinlock_t can be
> excluded.

Unfortunately it can't be excluded. See net/unix/af_unix.c, which uses
unix_state_lock(), a spinlock, around printk(%pK).

> If the usage is intended to happen only from task context then
> in_task() would make sense. This would already ban any softirq context
> and everything else I know we had in the past.

%pK only makes sense from task context. There should also be an assertion
if this is violated independently of the value of kptr_restrict.

Also in_task() looks like the better replacement for this check in
restricted_pointer():

	if (in_hardirq() || in_serving_softirq() || in_nmi())

> The fake spinlock_t could be achieved by just something like
> might_lock() which would avoid any overhead of real locking.

might_lock() simulates and acquisition and immediate release of the lock.
With an alternative solution which holds the fake lock for the whole
execution of restricted_pointer() we could make sure that lockdep
can detect any incompatible locks being taken in the callees, even if
the actual caller of restrict_pointer() is not currently holding any
spinlocks which would trigger such a warning.
I'm happy about opinions whether this is useful.

> But do we still need %pK? There are far more %p users in seq_printf()
> context as per
> 	git grep -E 'seq_printf.*%p\>'

That would probably be a question for the networking folks who are using it.
Getting rid of it would certainly make various things easier.

> than %pK. According to commit 312b4e226951f ("vsprintf: check real
> user/group id for %pK") it is temporary as of 2013. There should be a
> check at open time instead.

Doing the check at open time requires some place to store the result
of it. The users of %pK I looked at all reused their core datastructures
as state in seq_file, so finding space for the result from open time
would require some non-trivial changes to them.

> > > 
> > > >  	switch (kptr_restrict) {
> > > >  	case 0:
> > > >  		/* Handle as %p, hash and do _not_ leak addresses. */


Thomas

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Sebastian Andrzej Siewior]

On 2026-03-18 15:45:06 [+0100], Thomas Weißschuh wrote:
> > might_sleep() seems reasonable if any usage under spinlock_t can be
> > excluded.
> 
> Unfortunately it can't be excluded. See net/unix/af_unix.c, which uses
> unix_state_lock(), a spinlock, around printk(%pK).

So if the security code can't use a mutex_t internally as locking then
we can't do might_sleep() then.

> > If the usage is intended to happen only from task context then
> > in_task() would make sense. This would already ban any softirq context
> > and everything else I know we had in the past.
> 
> %pK only makes sense from task context. There should also be an assertion
> if this is violated independently of the value of kptr_restrict.
> 
> Also in_task() looks like the better replacement for this check in
> restricted_pointer():
> 
> 	if (in_hardirq() || in_serving_softirq() || in_nmi())

exactly.

> > The fake spinlock_t could be achieved by just something like
> > might_lock() which would avoid any overhead of real locking.
> 
> might_lock() simulates and acquisition and immediate release of the lock.
> With an alternative solution which holds the fake lock for the whole
> execution of restricted_pointer() we could make sure that lockdep
> can detect any incompatible locks being taken in the callees, even if
> the actual caller of restrict_pointer() is not currently holding any
> spinlocks which would trigger such a warning.
> I'm happy about opinions whether this is useful.

might_lock() just grabs and releases it. You could acquire it at the top
and drop it at the end. In order to simulate a lock+unlock behaviour
without an actual lock.

> > But do we still need %pK? There are far more %p users in seq_printf()
> > context as per
> > 	git grep -E 'seq_printf.*%p\>'
> 
> That would probably be a question for the networking folks who are using it.
> Getting rid of it would certainly make various things easier.

Lets see what Kees says, then maybe poke the netdev unless Kees explains
why this need to remain.

> > than %pK. According to commit 312b4e226951f ("vsprintf: check real
> > user/group id for %pK") it is temporary as of 2013. There should be a
> > check at open time instead.
> 
> Doing the check at open time requires some place to store the result
> of it. The users of %pK I looked at all reused their core datastructures
> as state in seq_file, so finding space for the result from open time
> would require some non-trivial changes to them.

You could go for the easy solution and return early with -EACCES or so.
That was the intention according to my understanding.

> > > > >  	switch (kptr_restrict) {
> > > > >  	case 0:
> > > > >  		/* Handle as %p, hash and do _not_ leak addresses. */
> 
> 
> Thomas

Sebastian

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Thomas Weißschuh]

On Wed, Mar 18, 2026 at 03:57:18PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-03-18 15:45:06 [+0100], Thomas Weißschuh wrote:
> > > might_sleep() seems reasonable if any usage under spinlock_t can be
> > > excluded.
> > 
> > Unfortunately it can't be excluded. See net/unix/af_unix.c, which uses
> > unix_state_lock(), a spinlock, around printk(%pK).
> 
> So if the security code can't use a mutex_t internally as locking then
> we can't do might_sleep() then.

Yep.

(...)

> > > The fake spinlock_t could be achieved by just something like
> > > might_lock() which would avoid any overhead of real locking.
> > 
> > might_lock() simulates and acquisition and immediate release of the lock.
> > With an alternative solution which holds the fake lock for the whole
> > execution of restricted_pointer() we could make sure that lockdep
> > can detect any incompatible locks being taken in the callees, even if
> > the actual caller of restrict_pointer() is not currently holding any
> > spinlocks which would trigger such a warning.
> > I'm happy about opinions whether this is useful.
> 
> might_lock() just grabs and releases it. You could acquire it at the top
> and drop it at the end. In order to simulate a lock+unlock behaviour
> without an actual lock.

That was my plan. My current idea uses a raw 'struct lockdep_map'
without a dummy spinlock, as the spinlock would never be used anyways.
But if the dummy spinlock would be better for some reason, let's use that.

(...)

> > > than %pK. According to commit 312b4e226951f ("vsprintf: check real
> > > user/group id for %pK") it is temporary as of 2013. There should be a
> > > check at open time instead.
> > 
> > Doing the check at open time requires some place to store the result
> > of it. The users of %pK I looked at all reused their core datastructures
> > as state in seq_file, so finding space for the result from open time
> > would require some non-trivial changes to them.
> 
> You could go for the easy solution and return early with -EACCES or so.
> That was the intention according to my understanding.

My understanding is different. The file should be readable for everybody.
But the actual contents depend on the user reading it. The clean solution
would be to check the user during open() and decide once if the pointers
should be printed raw/hashed/zeroed out.

The fact that even 13 years later there are no helpers whatsoever for
users to do the checks at open() time and later do the formatting,
probably didn't help the adoption of that scheme.


Thomas

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[Sebastian Andrzej Siewior]

On 2026-03-18 16:10:24 [+0100], Thomas Weißschuh wrote:
> That was my plan. My current idea uses a raw 'struct lockdep_map'
> without a dummy spinlock, as the spinlock would never be used anyways.
> But if the dummy spinlock would be better for some reason, let's use that.

just lockdep is fine. It is just annotation & verification at runtime,
no actual locking is needed/ intended.

> > > > than %pK. According to commit 312b4e226951f ("vsprintf: check real
> > > > user/group id for %pK") it is temporary as of 2013. There should be a
> > > > check at open time instead.
> > > 
> > > Doing the check at open time requires some place to store the result
> > > of it. The users of %pK I looked at all reused their core datastructures
> > > as state in seq_file, so finding space for the result from open time
> > > would require some non-trivial changes to them.
> > 
> > You could go for the easy solution and return early with -EACCES or so.
> > That was the intention according to my understanding.
> 
> My understanding is different. The file should be readable for everybody.
> But the actual contents depend on the user reading it. The clean solution
> would be to check the user during open() and decide once if the pointers
> should be printed raw/hashed/zeroed out.
> 
> The fact that even 13 years later there are no helpers whatsoever for
> users to do the checks at open() time and later do the formatting,
> probably didn't help the adoption of that scheme.

I don't recall needing ever pointer for other reasons than debugging.

> Thomas

Sebastian

Re: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

[kernel test robot]

Hello,

kernel test robot noticed "BUG:sleeping_function_called_from_invalid_context_at_lib/vsprintf.c" on:

commit: a3aa148a203538960cf380021ba5605a35dd573b ("[PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting")
url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Wei-schuh/lib-vsprintf-Validate-sleepable-context-during-restrictred-pointer-formatting/20260318-000650
patch link: https://lore.kernel.org/all/20260317-restricted-pointers-final-v1-1-b4dca0ed6483@linutronix.de/
patch subject: [PATCH] lib/vsprintf: Validate sleepable context during restrictred pointer formatting

in testcase: trinity
version: 
with following parameters:

	runtime: 300s
	group: group-00
	nr_groups: 5



config: x86_64-kexec
compiler: clang-20
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 32G

(please refer to attached dmesg/kmsg for entire log/backtrace)


+---------------------------------------------------------------------+------------+------------+
|                                                                     | 2d1373e424 | a3aa148a20 |
+---------------------------------------------------------------------+------------+------------+
| BUG:sleeping_function_called_from_invalid_context_at_lib/vsprintf.c | 0          | 12         |
+---------------------------------------------------------------------+------------+------------+

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202603191629.80fc4e2b-lkp@intel.com



[  103.203896][ T6289] BUG: sleeping function called from invalid context at lib/vsprintf.c:866
[  103.218966][ T6289] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6289, name: trinity-c6
[  103.270174][ T6289] preempt_count: 2, expected: 0
[  103.288514][ T6289] RCU nest depth: 0, expected: 0
[  103.310869][ T6289] CPU: 1 UID: 65534 PID: 6289 Comm: trinity-c6 Not tainted 7.0.0-rc4-00006-ga3aa148a2035 #1 PREEMPT(lazy)
[  103.310904][ T6289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  103.310929][ T6289] Call Trace:
[  103.311096][ T6289]  <TASK>
[  103.311126][ T6289]  dump_stack_lvl (lib/dump_stack.c:123)
[  103.311160][ T6289]  __might_resched (kernel/sched/core.c:8889)
[  103.311196][ T6289]  restricted_pointer (include/linux/kernel.h:58 lib/vsprintf.c:866)
[  103.311228][ T6289]  pointer (lib/vsprintf.c:2624)
[  103.311261][ T6289]  ? vsnprintf (lib/vsprintf.c:?)
[  103.311295][ T6289]  vsnprintf (lib/vsprintf.c:2955)
[  103.311327][ T6289]  seq_vprintf (fs/seq_file.c:393)
[  103.311359][ T6289]  seq_printf (fs/seq_file.c:409)
[  103.311388][ T6289]  ? rep_movs_alternative (arch/x86/lib/copy_user_64.S:46)
[  103.311423][ T6289]  unix_seq_show (net/unix/af_unix.c:3540)
[  103.311458][ T6289]  seq_read_iter (fs/seq_file.c:273)
[  103.311491][ T6289]  seq_read (fs/seq_file.c:164)
[  103.311524][ T6289]  proc_reg_read (fs/proc/inode.c:308 fs/proc/inode.c:320)
[  103.311580][ T6289]  vfs_read (fs/read_write.c:572)
[  103.311611][ T6289]  ? do_setitimer (include/linux/spinlock.h:?)
[  103.311643][ T6289]  ksys_read (fs/read_write.c:717)
[  103.311674][ T6289]  do_syscall_64 (arch/x86/entry/syscall_64.c:?)
[  103.311708][ T6289]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[  103.311739][ T6289] RIP: 0033:0x453b29
[  103.311749][ T6289] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 84 00 00 c3 66 2e 0f 1f 84 00 00 00 00
All code
========
   0:	00 f3                	add    %dh,%bl
   2:	c3                   	ret
   3:	66 2e 0f 1f 84 00 00 	cs nopw 0x0(%rax,%rax,1)
   a:	00 00 00 
   d:	0f 1f 40 00          	nopl   0x0(%rax)
  11:	48 89 f8             	mov    %rdi,%rax
  14:	48 89 f7             	mov    %rsi,%rdi
  17:	48 89 d6             	mov    %rdx,%rsi
  1a:	48 89 ca             	mov    %rcx,%rdx
  1d:	4d 89 c2             	mov    %r8,%r10
  20:	4d 89 c8             	mov    %r9,%r8
  23:	4c 8b 4c 24 08       	mov    0x8(%rsp),%r9
  28:	0f 05                	syscall
  2a:*	48 3d 01 f0 ff ff    	cmp    $0xfffffffffffff001,%rax		<-- trapping instruction
  30:	0f 83 3b 84 00 00    	jae    0x8471
  36:	c3                   	ret
  37:	66                   	data16
  38:	2e                   	cs
  39:	0f                   	.byte 0xf
  3a:	1f                   	(bad)
  3b:	84 00                	test   %al,(%rax)
  3d:	00 00                	add    %al,(%rax)
	...

Code starting with the faulting instruction
===========================================
   0:	48 3d 01 f0 ff ff    	cmp    $0xfffffffffffff001,%rax
   6:	0f 83 3b 84 00 00    	jae    0x8447
   c:	c3                   	ret
   d:	66                   	data16
   e:	2e                   	cs
   f:	0f                   	.byte 0xf
  10:	1f                   	(bad)
  11:	84 00                	test   %al,(%rax)
  13:	00 00                	add    %al,(%rax)
	...
[  103.311777][ T6289] RSP: 002b:00007ffe20169d38 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[  103.311807][ T6289] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000453b29
[  103.311812][ T6289] RDX: 0000000000001000 RSI: 00007f14e38d0000 RDI: 00000000000000b6
[  103.311837][ T6289] RBP: 00007ffe20169de0 R08: 000000000000ffff R09: 23c080ca08458805
[  103.311842][ T6289] R10: fffffffffffffffd R11: 0000000000000246 R12: 0000000000000002
[  103.311846][ T6289] R13: 00007f14e41df058 R14: 00000000010a2830 R15: 00007f14e41df000
[  103.311877][ T6289]  </TASK>



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260319/202603191629.80fc4e2b-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki