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:
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
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
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).
>
>
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() #
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
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
> +++
> > 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
> >
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
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
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
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
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
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
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
> > >
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
> > >
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
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
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...
> > >>>
> > >>>
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
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
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
>>
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
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(); #
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
> >
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
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
> > [
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
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
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
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
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
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
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!
--
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
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.
36 matches
Mail list logo