Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-02 Thread Heiko Carstens
On Wed, Dec 02, 2020 at 11:16:05AM +, Mark Rutland wrote: > On Wed, Dec 02, 2020 at 11:56:49AM +0100, Heiko Carstens wrote: > > From 7bd86fb3eb039a4163281472ca79b9158e726526 Mon Sep 17 00:00:00 2001 > > From: Heiko Carstens > > Date: Wed, 2 Dec 2020 11:46:01 +0100 > > Subject: [PATCH] s390:

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-02 Thread Peter Zijlstra
On Wed, Dec 02, 2020 at 11:56:49AM +0100, Heiko Carstens wrote: > From 7bd86fb3eb039a4163281472ca79b9158e726526 Mon Sep 17 00:00:00 2001 > From: Heiko Carstens > Date: Wed, 2 Dec 2020 11:46:01 +0100 > Subject: [PATCH] s390: fix irq state tracing > > With commit 58c644ba512c ("sched/idle: Fix

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-02 Thread Mark Rutland
On Wed, Dec 02, 2020 at 11:56:49AM +0100, Heiko Carstens wrote: > From 7bd86fb3eb039a4163281472ca79b9158e726526 Mon Sep 17 00:00:00 2001 > From: Heiko Carstens > Date: Wed, 2 Dec 2020 11:46:01 +0100 > Subject: [PATCH] s390: fix irq state tracing > > With commit 58c644ba512c ("sched/idle: Fix

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-02 Thread Heiko Carstens
On Wed, Dec 02, 2020 at 10:21:16AM +0100, Peter Zijlstra wrote: > On Tue, Dec 01, 2020 at 08:18:56PM +0100, Heiko Carstens wrote: > OK, so with a little help from s390/PoO and Sven, the code removed skips > the TRACE_IRQS_OFF when IRQs were enabled in the old PSW (the previous > context). > >

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-02 Thread Heiko Carstens
On Wed, Dec 02, 2020 at 10:38:05AM +0100, Peter Zijlstra wrote: > On Wed, Dec 02, 2020 at 08:54:27AM +0100, Heiko Carstens wrote: > > > > But but but... > > > > > > > > do_idle() # IRQs on > > > > local_irq_disable();# IRQs off > > > > defaul_idle_call() #

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-02 Thread Peter Zijlstra
On Wed, Dec 02, 2020 at 08:54:27AM +0100, Heiko Carstens wrote: > > > But but but... > > > > > > do_idle() # IRQs on > > > local_irq_disable(); # IRQs off > > > defaul_idle_call()# IRQs off > > lockdep_hardirqs_on(); # IRQs off, but lockdep things they're

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-02 Thread Peter Zijlstra
On Tue, Dec 01, 2020 at 08:18:56PM +0100, Heiko Carstens wrote: > Is there a reason why this should be considered broken? AFAICT this is good. > diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S > index 26bb0603c5a1..92beb1444644 100644 > --- a/arch/s390/kernel/entry.S > +++

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Heiko Carstens
> > But but but... > > > > do_idle() # IRQs on > > local_irq_disable();# IRQs off > > defaul_idle_call() # IRQs off > lockdep_hardirqs_on(); # IRQs off, but lockdep things they're on > > arch_cpu_idle() # IRQs off > >

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Peter Zijlstra
On Tue, Dec 01, 2020 at 11:45:25AM -0800, Linus Torvalds wrote: > On Mon, Nov 30, 2020 at 11:56 PM Peter Zijlstra wrote: > > > > So even if an architecture needs to enable interrupts on idle, we need > > it disabled again when coming out. So we might as well have the arch > > idle routine then

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Linus Torvalds
On Mon, Nov 30, 2020 at 11:56 PM Peter Zijlstra wrote: > > So even if an architecture needs to enable interrupts on idle, we need > it disabled again when coming out. So we might as well have the arch > idle routine then be: STI; HLT; CLI; because then architectures than can > idle with

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Heiko Carstens
On Tue, Dec 01, 2020 at 08:14:41PM +0100, Peter Zijlstra wrote: > On Tue, Dec 01, 2020 at 06:57:37PM +, Mark Rutland wrote: > > On Tue, Dec 01, 2020 at 07:15:06PM +0100, Peter Zijlstra wrote: > > > On Tue, Dec 01, 2020 at 03:55:19PM +0100, Peter Zijlstra wrote: > > > > On Tue, Dec 01, 2020 at

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Peter Zijlstra
On Tue, Dec 01, 2020 at 06:57:37PM +, Mark Rutland wrote: > On Tue, Dec 01, 2020 at 07:15:06PM +0100, Peter Zijlstra wrote: > > On Tue, Dec 01, 2020 at 03:55:19PM +0100, Peter Zijlstra wrote: > > > On Tue, Dec 01, 2020 at 06:46:44AM -0800, Paul E. McKenney wrote: > > > > > > > > So after

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Mark Rutland
On Tue, Dec 01, 2020 at 07:15:06PM +0100, Peter Zijlstra wrote: > On Tue, Dec 01, 2020 at 03:55:19PM +0100, Peter Zijlstra wrote: > > On Tue, Dec 01, 2020 at 06:46:44AM -0800, Paul E. McKenney wrote: > > > > > > So after having talked to Sven a bit, the thing that is happening, is > > > > that

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Peter Zijlstra
On Tue, Dec 01, 2020 at 07:15:06PM +0100, Peter Zijlstra wrote: > On Tue, Dec 01, 2020 at 03:55:19PM +0100, Peter Zijlstra wrote: > > On Tue, Dec 01, 2020 at 06:46:44AM -0800, Paul E. McKenney wrote: > > > > > > So after having talked to Sven a bit, the thing that is happening, is > > > > that

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Peter Zijlstra
On Tue, Dec 01, 2020 at 03:55:19PM +0100, Peter Zijlstra wrote: > On Tue, Dec 01, 2020 at 06:46:44AM -0800, Paul E. McKenney wrote: > > > > So after having talked to Sven a bit, the thing that is happening, is > > > that this is the one place where we take interrupts with RCU being > > >

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Paul E. McKenney
On Tue, Dec 01, 2020 at 03:55:19PM +0100, Peter Zijlstra wrote: > On Tue, Dec 01, 2020 at 06:46:44AM -0800, Paul E. McKenney wrote: > > > > So after having talked to Sven a bit, the thing that is happening, is > > > that this is the one place where we take interrupts with RCU being > > >

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Peter Zijlstra
On Tue, Dec 01, 2020 at 06:46:44AM -0800, Paul E. McKenney wrote: > > So after having talked to Sven a bit, the thing that is happening, is > > that this is the one place where we take interrupts with RCU being > > disabled. Normally RCU is watching and all is well, except during idle. > > Isn't

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Paul E. McKenney
On Tue, Dec 01, 2020 at 12:07:24PM +0100, Peter Zijlstra wrote: > On Tue, Dec 01, 2020 at 09:07:34AM +0100, Peter Zijlstra wrote: > > On Mon, Nov 30, 2020 at 08:31:32PM +0100, Christian Borntraeger wrote: > > > On 30.11.20 19:04, Linus Torvalds wrote: > > > > On Mon, Nov 30, 2020 at 5:03 AM Peter

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Peter Zijlstra
On Tue, Dec 01, 2020 at 09:07:34AM +0100, Peter Zijlstra wrote: > On Mon, Nov 30, 2020 at 08:31:32PM +0100, Christian Borntraeger wrote: > > On 30.11.20 19:04, Linus Torvalds wrote: > > > On Mon, Nov 30, 2020 at 5:03 AM Peter Zijlstra > > > wrote: > > >> > > >>> But but but... > > >>> > > >>>

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-12-01 Thread Peter Zijlstra
On Mon, Nov 30, 2020 at 08:31:32PM +0100, Christian Borntraeger wrote: > On 30.11.20 19:04, Linus Torvalds wrote: > > On Mon, Nov 30, 2020 at 5:03 AM Peter Zijlstra wrote: > >> > >>> But but but... > >>> > >>> do_idle() # IRQs on > >>> local_irq_disable(); # IRQs off

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Peter Zijlstra
On Tue, Dec 01, 2020 at 08:39:06AM +0100, Peter Zijlstra wrote: > On Mon, Nov 30, 2020 at 09:55:44AM -0800, Linus Torvalds wrote: > > > Yes, yes, I can very well imagine some hardware doing a "idle until > > you sense an interrupt, but don't actually take it". It's not > > _impossible_. But it's

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Sven Schnelle
Hi Peter, Peter Zijlstra writes: > On Mon, Nov 30, 2020 at 01:52:11PM +0100, Peter Zijlstra wrote: >> On Mon, Nov 30, 2020 at 01:31:33PM +0100, Sven Schnelle wrote: >> > [0.670280] [ cut here ] >> > [0.670288] WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:1054 >>

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Peter Zijlstra
On Mon, Nov 30, 2020 at 09:55:44AM -0800, Linus Torvalds wrote: > Yes, yes, I can very well imagine some hardware doing a "idle until > you sense an interrupt, but don't actually take it". It's not > _impossible_. But it's certainly not normal. A lot of hardware actually does that, including

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Christian Borntraeger
On 30.11.20 19:04, Linus Torvalds wrote: > On Mon, Nov 30, 2020 at 5:03 AM Peter Zijlstra wrote: >> >>> But but but... >>> >>> do_idle() # IRQs on >>> local_irq_disable(); # IRQs off >>> defaul_idle_call()# IRQs off >> lockdep_hardirqs_on(); #

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Linus Torvalds
On Mon, Nov 30, 2020 at 5:03 AM Peter Zijlstra wrote: > > > But but but... > > > > do_idle() # IRQs on > > local_irq_disable(); # IRQs off > > defaul_idle_call()# IRQs off > lockdep_hardirqs_on(); # IRQs off, but lockdep things they're on > >

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Linus Torvalds
On Sun, Nov 29, 2020 at 11:57 PM Peter Zijlstra wrote: > > The idea was to flip all of arch_cpu_idle() to not enable interrupts. I don't think that's realistic. > This is suboptimal for things like x86 where arch_cpu_idle() is > basically STI;HLT, but x86 isn't likely to actually use this code

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Peter Zijlstra
On Mon, Nov 30, 2020 at 01:52:11PM +0100, Peter Zijlstra wrote: > On Mon, Nov 30, 2020 at 01:31:33PM +0100, Sven Schnelle wrote: > > [0.670280] [ cut here ] > > [0.670288] WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:1054 > > rcu_irq_enter+0x7e/0xa8 > > [

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Peter Zijlstra
On Mon, Nov 30, 2020 at 01:31:33PM +0100, Sven Schnelle wrote: > [0.670280] [ cut here ] > [0.670288] WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:1054 > rcu_irq_enter+0x7e/0xa8 > [0.670293] Modules linked in: > [0.670299] CPU: 1 PID: 0 Comm: swapper/1

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Sven Schnelle
Hi, Sven Schnelle writes: > Hi Peter, > > Peter Zijlstra writes: > >> On Sun, Nov 29, 2020 at 11:31:41AM -0800, Linus Torvalds wrote: >>> On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner wrote: >>> > >>> > Yet two more places which invoke tracing from RCU disabled regions in the >>> > idle

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Peter Zijlstra
On Mon, Nov 30, 2020 at 08:56:51AM +0100, Peter Zijlstra wrote: > The idea was to flip all of arch_cpu_idle() to not enable interrupts. > > This is suboptimal for things like x86 where arch_cpu_idle() is > basically STI;HLT, but x86 isn't likely to actually use this code path > anyway, given all

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-30 Thread Sven Schnelle
Hi Peter, Peter Zijlstra writes: > On Sun, Nov 29, 2020 at 11:31:41AM -0800, Linus Torvalds wrote: >> On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner wrote: >> > >> > Yet two more places which invoke tracing from RCU disabled regions in the >> > idle path. Similar to the entry path the low

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-29 Thread Peter Zijlstra
On Sun, Nov 29, 2020 at 11:31:41AM -0800, Linus Torvalds wrote: > On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner wrote: > > > > Yet two more places which invoke tracing from RCU disabled regions in the > > idle path. Similar to the entry path the low level idle functions have to > > be

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-29 Thread Paul E. McKenney
On Sun, Nov 29, 2020 at 11:31:41AM -0800, Linus Torvalds wrote: > On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner wrote: > > > > Yet two more places which invoke tracing from RCU disabled regions in the > > idle path. Similar to the entry path the low level idle functions have to > > be

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-29 Thread pr-tracker-bot
The pull request you sent on Sun, 29 Nov 2020 13:38:00 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking-urgent-2020-11-29 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f91a3aa6bce480fe6e08df540129f4a923222419 Thank you! --

Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-29 Thread Linus Torvalds
On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner wrote: > > Yet two more places which invoke tracing from RCU disabled regions in the > idle path. Similar to the entry path the low level idle functions have to > be non-instrumentable. This really seems less than optimal. In particular, lookie

[GIT pull] locking/urgent for v5.10-rc6

2020-11-29 Thread Thomas Gleixner
Linus, please pull the latest locking/urgent branch from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-2020-11-29 up to: 6e1d2bc675bd: intel_idle: Fix intel_idle() vs tracing Yet two more places which invoke tracing from RCU disabled regions in the idle path.