From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF95D18D658 for ; Tue, 2 Jun 2026 08:18:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780388335; cv=none; b=AlLIQxUSksYiGn943aau/lS0kkAj5XGQ1NP5ysFbyZ1ftDDN0xJetSIU+bRUcPtB/9a4FlVrPuIGx5Uj95jzhaCFsdzEBG2YT0GFfEdlc1qGwRILc0EVimXVoNrSVpW8uYbvBng8LviXAQETifONR6nGI3xFkFUfRMOmyw1cEpQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780388335; c=relaxed/simple; bh=gxxmtxHxl3rVSfs3CLGEQKiKID1b6MKbcxQTxQSBhQA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tfDzwgteztFaYpXwLXSbZ2a7G6ftDEvpQds0zZGKzZu02TX5B1qvINU2mu4cXXtNmpGpsqOy2xQ65FvZFYZ/fs6D57zXHiM0hSEJjVF/21KW4T9l5UHYdZ2uw01jEapXmHEki9JQAVJotL4Q/XTWWiHLpKWuTucpEcM3Ri5vN50= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=NcOUVdW8; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="NcOUVdW8" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Eth7fFuHYGEZavWHClP4kKTw0ybwZVVXf+qx1PULgMA=; b=NcOUVdW8szMDtLxDzpaGR6UHW7 Y/vUvQRtcMzM8uhu831Jz3DjkIPF1hzpOfmjmBR71LEO5UXP1tPjbkKur/wR/8NOEq+kEDz+CpWun aDEfM+JP9qtT95fpyCQQvd4Q77xAAGyXWBSbZ1zuhD7uevnURoy+uiZ/luwhfpaK26OL8nCUKjNsm nbjGqsudOI/0OyVavlAv6ytSu7PoQBUv2VYIZcNhiLQRzVev1c9utwS7vikufn+WaN5oLzJRtinWz m9LOeCNEGC9vm4JJf27iZ/tgpTduIn8rCE/YG8hSamktxApepqQWAop1cx9HyooK3RPlWtaEroCj5 /abVELdA==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wUKKk-00000001akl-33HV; Tue, 02 Jun 2026 08:18:47 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id E542630019E; Tue, 02 Jun 2026 10:18:45 +0200 (CEST) Date: Tue, 2 Jun 2026 10:18:45 +0200 From: Peter Zijlstra To: Shrikanth Hegde Cc: Venkat Rao Bagalkote , Madhavan Srinivasan , Mukesh Kumar Chaurasiya , Ritesh Harjani , linuxppc-dev , LKML , Srikar Dronamraju Subject: Re: [linux-next20260529] kernel BUG at kernel/sched/core.c:7512! Message-ID: <20260602081845.GX3126523@noisy.programming.kicks-ass.net> References: <7904105b-9dfa-4efd-a5ef-bc0276ed255d@linux.ibm.com> <2f8c3d75-de2c-48bf-bd05-46b816d55c69@linux.ibm.com> <20260601095601.GN3102624@noisy.programming.kicks-ass.net> <37e69c39-564b-4ca9-bb27-1b99faab540c@linux.ibm.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <37e69c39-564b-4ca9-bb27-1b99faab540c@linux.ibm.com> On Tue, Jun 02, 2026 at 01:26:48PM +0530, Shrikanth Hegde wrote: > > > On 6/1/26 3:26 PM, Peter Zijlstra wrote: > > On Mon, Jun 01, 2026 at 02:46:24PM +0530, Shrikanth Hegde wrote: > > > > > Ritesh, Mukesh, Is below possible scenario? > > > > > > do_page_fault seems to enable irq's in the interrupt handler? > > > is that expected? if so, one might see > > > > > > -- do_page_fault (enter kernel mode) > > > -- enables interrupts > > > -- gets interrupt - Sets need_resched. > > > -- irqentry_exit - Sees it is kernel mode. Just checks preempt count > > > and calls preempt_schedule_irq, which catches both > > > preempt_count and !irqs_disabled. Hence the panic? > > > > > > Should do_page_fault do preempt_disable when it enables the interrupts? > > > > No, it is expected for page-fault to be able to schedule. Specifically, > > it must be able to sleep to support loading pages from disk. > > Oh yes. Ok. Thanks for taking a look. > > > > > Please check the value of preempt_count() (does it perchance have > > HARDIRQ_OFFSET?). Also, if the fault handler does enable IRQs, it must > > also disable them again once done. > > Will check it. > > > > > Notably, I see ___do_page_fault() do interrupt_cond_loadl_irq_enable(), > > but I'm not seeing a local_irq_disable() to match! > > Yes, that's likely the culprit. It is possible that ___do_page_fault runs for longer > and it may set need_resched. If it was in kernel mode, then it may not disable the > interrupt and then subsequent irqentry_exit panics. > > BTW I was able to consistently repro this on P9 with hackbench as below. > > for i in {0..10}; do ./hackbench 10 process 10000 loops; done; > for i in {0..10}; do ./hackbench 20 process 10000 loops; done; > for i in {0..10}; do ./hackbench 30 process 10000 loops; done; > for i in {0..10}; do ./hackbench 40 process 10000 loops; done; << usually panics here. > for i in {0..10}; do ./hackbench 10 thread 10000 loops; done; > for i in {0..10}; do ./hackbench 20 thread 10000 loops; done; > for i in {0..10}; do ./hackbench -pipe 10 process 10000 loops; done; > for i in {0..10}; do ./hackbench -pipe 20 process 10000 loops; done; > for i in {0..10}; do ./hackbench -pipe 30 process 10000 loops; done; > for i in {0..10}; do ./hackbench -pipe 40 process 10000 loops; done; > for i in {0..10}; do ./hackbench -pipe 10 thread 10000 loops; done; > for i in {0..10}; do ./hackbench -pipe 20 thread 10000 loops; done; > > Note, if i run ./hackbench 40 process 10000 loops alone, it doesn't panic. > Likely some continous stressing needed to get into this case. > > Below diff helps to fix it. With it see test passes. Hackbench numbers aren't super happy > about it. It is regressing a bit compared to baseline. But no panic atleast. > AND i have changed the BUG_ON to WARN_ON as irq_disabled right after. We could still fix the > call sites if the warning is seen. > > diff --git a/arch/powerpc/include/asm/entry-common.h b/arch/powerpc/include/asm/entry-common.h > index de5601282755..7da373a56813 100644 > --- a/arch/powerpc/include/asm/entry-common.h > +++ b/arch/powerpc/include/asm/entry-common.h > @@ -253,16 +253,17 @@ static inline void arch_interrupt_enter_prepare(struct pt_regs *regs) > static inline void arch_interrupt_exit_prepare(struct pt_regs *regs) > { > if (user_mode(regs)) { > - BUG_ON(regs_is_unrecoverable(regs)); > - BUG_ON(regs_irqs_disabled(regs)); > + WARN_ON(regs_is_unrecoverable(regs)); > + WARN_ON(regs_irqs_disabled(regs)); > /* > * We don't need to restore AMR on the way back to userspace for KUAP. > * AMR can only have been unlocked if we interrupted the kernel. > */ > kuap_assert_locked(); > - > - local_irq_disable(); > } > + > + /* irqentry_exit expects to be called with interrupts disabled */ > + local_irq_disable(); > } > static inline void arch_interrupt_async_enter_prepare(struct pt_regs *regs) > I would suggest trying something a little more focussed like so: diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c index 806c74e0d5ab..b002c179415c 100644 --- a/arch/powerpc/mm/fault.c +++ b/arch/powerpc/mm/fault.c @@ -589,6 +589,7 @@ static __always_inline void __do_page_fault(struct pt_regs *regs) err = ___do_page_fault(regs, regs->dar, regs->dsisr); if (unlikely(err)) bad_page_fault(regs, err); + local_irq_disable(); } DEFINE_INTERRUPT_HANDLER(do_page_fault) Since only ___do_page_fault() will enable interrupts, you only need to disable them again on its return path.