linux-kernel - Re: [BUG] sleeping function called from invalid context at ./include/linux/sched/mm.h:321

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8a3b5e43-5d2a-4205-a24e-27148c968278@paulmck-laptop>
Date: Tue, 13 May 2025 10:01:10 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Marco Elver <elver@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org,
	kasan-dev@...glegroups.com, Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [BUG] sleeping function called from invalid context at
 ./include/linux/sched/mm.h:321

On Tue, May 13, 2025 at 09:39:45AM +0200, Thomas Gleixner wrote:
> On Mon, May 12 2025 at 16:47, Paul E. McKenney wrote:
> > I ran this on x86 with clang version 19.1.7 (CentOS 19.1.7-1.el9).
> >
> > See below for the full splat.  The TINY02 and SRCU-T scenarios are unique
> > in setting both CONFIG_SMP=n and CONFIG_PROVE_LOCKING=y.
> >
> > Bisection converges here:
> >
> > c836e5a70c59 ("genirq/chip: Rework irq_set_msi_desc_off()")
> >
> > The commit reverts cleanly, but results in the following build error:
> >
> > kernel/irq/chip.c:98:26: error: call to undeclared function 'irq_get_desc_lock'
> >
> > Thoughts?
> 
> Smells like what the top commit of the irq/core branch fixes:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=irq/core

OK, that is this one:

47af06c9d31f ("genirq: Consistently use '%u' format specifier for unsigned int variables")

This is printk() format change, which seems unlikely, but what do I
know?  Can't hurt to run a two-minute test...  Which fails.

Ah, you sent this email at 9:39AM your time, and that commit was queued
at 9:34AM your time.  The top of the stack at 9:39AM was this one:

b5fcb6898202 ("genirq: Ensure flags in lock guard is consistently initialized")

OK, early enabling of interrupts could be a bad thing, so I guess that I
don't feel so bad about failing to have spotted the problem by inspection.
And the test passes for both rcutorture scenarios, thank you!

I have to ask...  Will you be rebasing the fixes into the offending
commits for bisectability?

							Thanx, Paul