All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michel Lespinasse <michel@lespinasse.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michel Lespinasse <michel@lespinasse.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	vgupta@kernel.org,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	ulli.kroll@googlemail.com,
	Linus Walleij <linus.walleij@linaro.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	bcain@quicinc.com, Huacai Chen <chenhuacai@kernel.org>,
	kernel@xen0n.name, Geert Uytterhoeven <geert@linux-m68k.org>,
	sammy@sammy.net, Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	dinguyen@kernel.org, jonas@southpole.se,
	stefan.kristiansson@saunalahti.fi,
	Stafford Horne <shorne@gmail.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, David Miller <davem@davemloft.net>,
	Richard Weinberger <richard@nod.at>,
	anton.ivanov@cambridgegreys.com,
	Johannes Berg <johannes@sipsolutions.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	acme@kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	jolsa@kernel.org, namhyung@kernel.org,
	Juergen Gross <jgross@suse.com>,
	srivatsa@csail.mit.edu, amakhalov@vmware.com,
	pv-drivers@vmware.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>, Len Brown <lenb@kernel.org>,
	Pavel Machek <pavel@ucw.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Anup Patel <anup@brainfault.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Arnd Bergmann <arnd@arndb.de>, Yury Norov <yury.norov@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Steven Rostedt <rostedt@goodmis.org>,
	Petr Mladek <pmladek@suse.com>,
	senozhatsky@chromium.org, John Ogness <john.ogness@linutronix.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	quic_neeraju@quicinc.com, Josh Triplett <josh@joshtriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Benjamin Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	vschneid@redhat.com, jpoimboe@kernel.org,
	linux-alpha@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-snps-arc@lists.infradead.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	openrisc@lists.librecores.org,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-s390@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, linux-xtensa@linux-xtensa.org,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	rcu@vger.kernel.org, rh0@fb.com
Subject: Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
Date: Sat, 30 Jul 2022 02:48:00 -0700	[thread overview]
Message-ID: <20220730094800.GB1587@lespinasse.org> (raw)
In-Reply-To: <CAJZ5v0gyPtX=ksCibo2ZN_BztCqUn9KRtRu+gsJ5KetB_1MwEQ@mail.gmail.com>

On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> <michel@lespinasse.org> wrote:
> >
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > > Xeons") wrecked intel_idle in two ways:
> > > > >
> > > > >  - must not have tracing in idle functions
> > > > >  - must return with IRQs disabled
> > > > >
> > > > > Additionally, it added a branch for no good reason.
> > > > >
> > > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > >
> > > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > > usage" when booting a kernel with debug options compiled in. Please
> > > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > > and is still present in v5.19-rc8.
> > > >
> > > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > >
> > > I finally got a chance to take a quick look at this.
> > >
> > > The rcu_eqs_exit() function is making a lockdep complaint about
> > > being invoked with interrupts enabled.  This function is called from
> > > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > > interrupts before invoking rcu_eqs_exit().
> > >
> > > The only other call to rcu_idle_exit() does not disable interrupts,
> > > but it is via rcu_user_exit(), which would be a very odd choice for
> > > cpuidle_enter_state().
> > >
> > > It seems unlikely, but it might be that it is the use of local_irq_save()
> > > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > > the trouble.  If this is the case, then the commit shown below would
> > > help.  Note that this commit removes the warning from lockdep, so it
> > > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > > equivalent debugging.
> > >
> > > Could you please try your test with the -rce commit shown below applied?
> >
> > Thanks for looking into it.
> >
> > After checking out Peter's commit 32d4fd5751ea,
> > cherry picking your commit ed4ae5eff4b3,
> > and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> > I am now seeing this a few seconds into the boot:
> >
> > [    3.010650] ------------[ cut here ]------------
> > [    3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 sched_clock_tick+0x27/0x60
> > [    3.010657] Modules linked in:
> > [    3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc1-test-00005-g1be22fea0611 #1
> > [    3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> > [    3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> > [    3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
> >  89 c0 48 03 1c c5 c0 98
> > [    3.010667] RSP: 0000:ffffffffb2803e28 EFLAGS: 00010002
> > [    3.010670] RAX: 0000000000000001 RBX: ffffc8ce7fa07060 RCX: 0000000000000001
> > [    3.010671] RDX: 0000000000000000 RSI: ffffffffb268dd21 RDI: ffffffffb269ab13
> > [    3.010673] RBP: 0000000000000001 R08: ffffffffffc300d5 R09: 000000000002be80
> > [    3.010674] R10: 000003625b53183a R11: ffffa012b802b7a4 R12: ffffffffb2aa9e80
> > [    3.010675] R13: ffffffffb2aa9e00 R14: 0000000000000001 R15: 0000000000000000
> > [    3.010677] FS:  0000000000000000(0000) GS:ffffa012b8000000(0000) knlGS:0000000000000000
> > [    3.010678] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    3.010680] CR2: ffffa012f81ff000 CR3: 0000000c99612001 CR4: 00000000003706f0
> > [    3.010681] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    3.010682] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [    3.010683] Call Trace:
> > [    3.010685]  <TASK>
> > [    3.010688]  cpuidle_enter_state+0xb7/0x4b0
> > [    3.010694]  cpuidle_enter+0x29/0x40
> > [    3.010697]  do_idle+0x1d4/0x210
> > [    3.010702]  cpu_startup_entry+0x19/0x20
> > [    3.010704]  rest_init+0x117/0x1a0
> > [    3.010708]  arch_call_rest_init+0xa/0x10
> > [    3.010711]  start_kernel+0x6d8/0x6ff
> > [    3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> > [    3.010728]  </TASK>
> > [    3.010729] irq event stamp: 44179
> > [    3.010730] hardirqs last  enabled at (44179): [<ffffffffb2000ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20
> > [    3.010734] hardirqs last disabled at (44177): [<ffffffffb22003f0>] __do_softirq+0x3f0/0x498
> > [    3.010736] softirqs last  enabled at (44178): [<ffffffffb2200332>] __do_softirq+0x332/0x498
> > [    3.010738] softirqs last disabled at (44171): [<ffffffffb16c760b>] irq_exit_rcu+0xab/0xf0
> > [    3.010741] ---[ end trace 0000000000000000 ]---
> 
> Can you please give this patch a go:
> https://patchwork.kernel.org/project/linux-pm/patch/Yt/AxPFi88neW7W5@e126311.manchester.arm.com/
> ?

I tried, but it didn't change the picture for me.

I'm not sure if that was the patch you meant to send though, as it
seems it's only adding a tracepoint so shouldn't make any difference
if I'm not actually using the tracepoint ?

WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <michel@lespinasse.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michel Lespinasse <michel@lespinasse.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	vgupta@kernel.org,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	ulli.kroll@googlemail.com,
	Linus Walleij <linus.walleij@linaro.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	bcain@quicinc.com, Huacai Chen <chenhuacai@kernel.org>,
	kernel@xen0n.name, Geert Uytterhoeven <geert@linux-m68k.org>,
	sammy@sammy.net, Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	dinguyen@kernel.org, jonas@southpole.se,
	stefan.kristiansson@saunalahti.fi,
	Stafford Horne <shorne@gmail.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, David Miller <davem@davemloft.net>,
	Richard Weinberger <richard@nod.at>,
	anton.ivanov@cambridgegreys.com,
	Johannes Berg <johannes@sipsolutions.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	acme@kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	jolsa@kernel.org, namhyung@kernel.org,
	Juergen Gross <jgross@suse.com>,
	srivatsa@csail.mit.edu, amakhalov@vmware.com,
	pv-drivers@vmware.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>, Len Brown <lenb@kernel.org>,
	Pavel Machek <pavel@ucw.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Anup Patel <anup@brainfault.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Arnd Bergmann <arnd@arndb.de>, Yury Norov <yury.norov@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Steven Rostedt <rostedt@goodmis.org>,
	Petr Mladek <pmladek@suse.com>,
	senozhatsky@chromium.org, John Ogness <john.ogness@linutronix.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	quic_neeraju@quicinc.com, Josh Triplett <josh@joshtriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Benjamin Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	vschneid@redhat.com, jpoimboe@kernel.org,
	linux-alpha@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-snps-arc@lists.infradead.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	openrisc@lists.librecores.org,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-s390@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, linux-xtensa@linux-xtensa.org,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	rcu@vger.kernel.org, rh0@fb.com
Subject: Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
Date: Sat, 30 Jul 2022 02:48:00 -0700	[thread overview]
Message-ID: <20220730094800.GB1587@lespinasse.org> (raw)
In-Reply-To: <CAJZ5v0gyPtX=ksCibo2ZN_BztCqUn9KRtRu+gsJ5KetB_1MwEQ@mail.gmail.com>

On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> <michel@lespinasse.org> wrote:
> >
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > > Xeons") wrecked intel_idle in two ways:
> > > > >
> > > > >  - must not have tracing in idle functions
> > > > >  - must return with IRQs disabled
> > > > >
> > > > > Additionally, it added a branch for no good reason.
> > > > >
> > > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > >
> > > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > > usage" when booting a kernel with debug options compiled in. Please
> > > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > > and is still present in v5.19-rc8.
> > > >
> > > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > >
> > > I finally got a chance to take a quick look at this.
> > >
> > > The rcu_eqs_exit() function is making a lockdep complaint about
> > > being invoked with interrupts enabled.  This function is called from
> > > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > > interrupts before invoking rcu_eqs_exit().
> > >
> > > The only other call to rcu_idle_exit() does not disable interrupts,
> > > but it is via rcu_user_exit(), which would be a very odd choice for
> > > cpuidle_enter_state().
> > >
> > > It seems unlikely, but it might be that it is the use of local_irq_save()
> > > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > > the trouble.  If this is the case, then the commit shown below would
> > > help.  Note that this commit removes the warning from lockdep, so it
> > > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > > equivalent debugging.
> > >
> > > Could you please try your test with the -rce commit shown below applied?
> >
> > Thanks for looking into it.
> >
> > After checking out Peter's commit 32d4fd5751ea,
> > cherry picking your commit ed4ae5eff4b3,
> > and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> > I am now seeing this a few seconds into the boot:
> >
> > [    3.010650] ------------[ cut here ]------------
> > [    3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 sched_clock_tick+0x27/0x60
> > [    3.010657] Modules linked in:
> > [    3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc1-test-00005-g1be22fea0611 #1
> > [    3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> > [    3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> > [    3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
> >  89 c0 48 03 1c c5 c0 98
> > [    3.010667] RSP: 0000:ffffffffb2803e28 EFLAGS: 00010002
> > [    3.010670] RAX: 0000000000000001 RBX: ffffc8ce7fa07060 RCX: 0000000000000001
> > [    3.010671] RDX: 0000000000000000 RSI: ffffffffb268dd21 RDI: ffffffffb269ab13
> > [    3.010673] RBP: 0000000000000001 R08: ffffffffffc300d5 R09: 000000000002be80
> > [    3.010674] R10: 000003625b53183a R11: ffffa012b802b7a4 R12: ffffffffb2aa9e80
> > [    3.010675] R13: ffffffffb2aa9e00 R14: 0000000000000001 R15: 0000000000000000
> > [    3.010677] FS:  0000000000000000(0000) GS:ffffa012b8000000(0000) knlGS:0000000000000000
> > [    3.010678] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    3.010680] CR2: ffffa012f81ff000 CR3: 0000000c99612001 CR4: 00000000003706f0
> > [    3.010681] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    3.010682] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [    3.010683] Call Trace:
> > [    3.010685]  <TASK>
> > [    3.010688]  cpuidle_enter_state+0xb7/0x4b0
> > [    3.010694]  cpuidle_enter+0x29/0x40
> > [    3.010697]  do_idle+0x1d4/0x210
> > [    3.010702]  cpu_startup_entry+0x19/0x20
> > [    3.010704]  rest_init+0x117/0x1a0
> > [    3.010708]  arch_call_rest_init+0xa/0x10
> > [    3.010711]  start_kernel+0x6d8/0x6ff
> > [    3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> > [    3.010728]  </TASK>
> > [    3.010729] irq event stamp: 44179
> > [    3.010730] hardirqs last  enabled at (44179): [<ffffffffb2000ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20
> > [    3.010734] hardirqs last disabled at (44177): [<ffffffffb22003f0>] __do_softirq+0x3f0/0x498
> > [    3.010736] softirqs last  enabled at (44178): [<ffffffffb2200332>] __do_softirq+0x332/0x498
> > [    3.010738] softirqs last disabled at (44171): [<ffffffffb16c760b>] irq_exit_rcu+0xab/0xf0
> > [    3.010741] ---[ end trace 0000000000000000 ]---
> 
> Can you please give this patch a go:
> https://patchwork.kernel.org/project/linux-pm/patch/Yt/AxPFi88neW7W5@e126311.manchester.arm.com/
> ?

I tried, but it didn't change the picture for me.

I'm not sure if that was the patch you meant to send though, as it
seems it's only adding a tracepoint so shouldn't make any difference
if I'm not actually using the tracepoint ?

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <michel@lespinasse.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michel Lespinasse <michel@lespinasse.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Benjamin Segall <bsegall@google.com>, Guo Ren <guoren@kernel.org>,
	Pavel Machek <pavel@ucw.cz>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	srivatsa@csail.mit.edu, linux-arch <linux-arch@vger.kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Huacai Chen <chenhuacai@kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Andy Gross <agross@kernel.org>, dl-linux-imx <linux-imx@nxp.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	xen-devel@lists.xenproject.org, Matt Turner <mattst88@gmail.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	sammy@sammy.net, Petr Mladek <pmladek@suse.com>,
	Linux PM <linux-pm@vger.kernel.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-um@lists.infradead.org, acme@kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Richard Henderson <rth@twiddle.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-perf-users@vger.kernel.org, senozhatsky@chromium.org,
	Sven Schnelle <svens@linux.ibm.com>,
	jolsa@kernel.org, Paul Mackerras <paulus@samba.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-ia64@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	virtualization@lists.linux-foundation.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	kernel@xen0n.name, quic_neeraju@quicinc.com,
	linux-s390@vger.kernel.org, vschneid@redhat.com,
	John Ogness <john.ogness@linutronix.de>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Will Deacon <will@kernel.org>, Helge Deller <deller@gmx.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Jon Hunter <jonathanh@nvidia.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Len Brown <lenb@kernel.org>,
	linux-xtensa@linux-xtensa.org,
	Sascha Hauer <kernel@pengutronix.de>,
	Vasily Gorbik <gor@linux.ibm.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-alpha@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Chris Zankel <chris@zankel.net>, Stephen Boyd <sboyd@kernel.org>,
	rh0@fb.com, dinguyen@kernel.org,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Joel Fernandes <joel@joelfernandes.org>,
	Fabio Estevam <festevam@gmail.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Kevin Hilman <khilman@kernel.org>,
	linux-csky@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
	linux-snps-arc@lists.infradead.org, Mel Gorman <mgorman@suse.de>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Yury Norov <yury.norov@gmail.com>,
	ulli.kroll@googlemail.com, vgupta@kernel.org,
	linux-clk <linux-clk@vger.kernel.org>,
	Michal Simek <monstr@monstr.eu>,
	Steven Rostedt <rostedt@goodmis.org>,
	rcu@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
	bcain@quicinc.com,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Parisc List <linux-parisc@vger.kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Shawn Guo <shawnguo@kernel.org>,
	David Miller <davem@davemloft.net>, Rich Felker <dalias@libc.org>,
	Peter Zijlstra <peterz@infradead.org>,
	amakhalov@vmware.com,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-riscv <linux-riscv@lists.infradead.org>,
	anton.ivanov@cambridgegreys.com, jonas@southpole.se,
	Arnd Bergmann <arnd@arndb.de>,
	Richard Weinberger <richard@nod.at>,
	the arch/x86 maintainers <x86@kernel.org>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Ingo Molnar <mingo@redhat.com>, Albert Ou <aou@eecs.berkeley.edu>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	openrisc@lists.librecores.org,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	namhyung@kernel.org,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	jpoimboe@kernel.org, Juergen Gross <jgross@suse.com>,
	pv-drivers@vmware.com,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Anup Patel <anup@brainfault.org>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Johannes Berg <johannes@sipsolutions.net>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
Date: Sat, 30 Jul 2022 02:48:00 -0700	[thread overview]
Message-ID: <20220730094800.GB1587@lespinasse.org> (raw)
In-Reply-To: <CAJZ5v0gyPtX=ksCibo2ZN_BztCqUn9KRtRu+gsJ5KetB_1MwEQ@mail.gmail.com>

On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> <michel@lespinasse.org> wrote:
> >
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > > Xeons") wrecked intel_idle in two ways:
> > > > >
> > > > >  - must not have tracing in idle functions
> > > > >  - must return with IRQs disabled
> > > > >
> > > > > Additionally, it added a branch for no good reason.
> > > > >
> > > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > >
> > > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > > usage" when booting a kernel with debug options compiled in. Please
> > > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > > and is still present in v5.19-rc8.
> > > >
> > > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > >
> > > I finally got a chance to take a quick look at this.
> > >
> > > The rcu_eqs_exit() function is making a lockdep complaint about
> > > being invoked with interrupts enabled.  This function is called from
> > > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > > interrupts before invoking rcu_eqs_exit().
> > >
> > > The only other call to rcu_idle_exit() does not disable interrupts,
> > > but it is via rcu_user_exit(), which would be a very odd choice for
> > > cpuidle_enter_state().
> > >
> > > It seems unlikely, but it might be that it is the use of local_irq_save()
> > > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > > the trouble.  If this is the case, then the commit shown below would
> > > help.  Note that this commit removes the warning from lockdep, so it
> > > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > > equivalent debugging.
> > >
> > > Could you please try your test with the -rce commit shown below applied?
> >
> > Thanks for looking into it.
> >
> > After checking out Peter's commit 32d4fd5751ea,
> > cherry picking your commit ed4ae5eff4b3,
> > and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> > I am now seeing this a few seconds into the boot:
> >
> > [    3.010650] ------------[ cut here ]------------
> > [    3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 sched_clock_tick+0x27/0x60
> > [    3.010657] Modules linked in:
> > [    3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc1-test-00005-g1be22fea0611 #1
> > [    3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> > [    3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> > [    3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
> >  89 c0 48 03 1c c5 c0 98
> > [    3.010667] RSP: 0000:ffffffffb2803e28 EFLAGS: 00010002
> > [    3.010670] RAX: 0000000000000001 RBX: ffffc8ce7fa07060 RCX: 0000000000000001
> > [    3.010671] RDX: 0000000000000000 RSI: ffffffffb268dd21 RDI: ffffffffb269ab13
> > [    3.010673] RBP: 0000000000000001 R08: ffffffffffc300d5 R09: 000000000002be80
> > [    3.010674] R10: 000003625b53183a R11: ffffa012b802b7a4 R12: ffffffffb2aa9e80
> > [    3.010675] R13: ffffffffb2aa9e00 R14: 0000000000000001 R15: 0000000000000000
> > [    3.010677] FS:  0000000000000000(0000) GS:ffffa012b8000000(0000) knlGS:0000000000000000
> > [    3.010678] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    3.010680] CR2: ffffa012f81ff000 CR3: 0000000c99612001 CR4: 00000000003706f0
> > [    3.010681] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    3.010682] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [    3.010683] Call Trace:
> > [    3.010685]  <TASK>
> > [    3.010688]  cpuidle_enter_state+0xb7/0x4b0
> > [    3.010694]  cpuidle_enter+0x29/0x40
> > [    3.010697]  do_idle+0x1d4/0x210
> > [    3.010702]  cpu_startup_entry+0x19/0x20
> > [    3.010704]  rest_init+0x117/0x1a0
> > [    3.010708]  arch_call_rest_init+0xa/0x10
> > [    3.010711]  start_kernel+0x6d8/0x6ff
> > [    3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> > [    3.010728]  </TASK>
> > [    3.010729] irq event stamp: 44179
> > [    3.010730] hardirqs last  enabled at (44179): [<ffffffffb2000ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20
> > [    3.010734] hardirqs last disabled at (44177): [<ffffffffb22003f0>] __do_softirq+0x3f0/0x498
> > [    3.010736] softirqs last  enabled at (44178): [<ffffffffb2200332>] __do_softirq+0x332/0x498
> > [    3.010738] softirqs last disabled at (44171): [<ffffffffb16c760b>] irq_exit_rcu+0xab/0xf0
> > [    3.010741] ---[ end trace 0000000000000000 ]---
> 
> Can you please give this patch a go:
> https://patchwork.kernel.org/project/linux-pm/patch/Yt/AxPFi88neW7W5@e126311.manchester.arm.com/
> ?

I tried, but it didn't change the picture for me.

I'm not sure if that was the patch you meant to send though, as it
seems it's only adding a tracepoint so shouldn't make any difference
if I'm not actually using the tracepoint ?

WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <michel@lespinasse.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michel Lespinasse <michel@lespinasse.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Benjamin Segall <bsegall@google.com>, Guo Ren <guoren@kernel.org>,
	Pavel Machek <pavel@ucw.cz>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	srivatsa@csail.mit.edu, linux-arch <linux-arch@vger.kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Andy Gross <agross@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	xen-devel@lists.xenproject.org, Matt Turner <mattst88@gmail.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	sammy@sammy.net, Petr Mladek <pmladek@suse.com>,
	Linux PM <linux-pm@vger.kernel.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-um@list s.infradead.org, acme@kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Richard Henderson <rth@twiddle.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-perf-users@vger.kernel.org, senozhatsky@chromium.org,
	Sven Schnelle <svens@linux.ibm.com>,
	jolsa@kernel.org, Paul Mackerras <paulus@samba.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-ia64@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	virtualization@lists.linux-foundation.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	kernel@xen0n.name, quic_neeraju@quicinc.com,
	linux-s390@vger.kernel.org, vschneid@redhat.com,
	John Ogness <john.ogness@linutronix.de>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Will Deacon <will@kernel.org>, Helge Deller <deller@gmx.de>,
	Danie l Lezcano <daniel.lezcano@linaro.org>,
	Jon Hunter <jonathanh@nvidia.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Len Brown <lenb@kernel.org>,
	linux-xtensa@linux-xtensa.org,
	Sascha Hauer <kernel@pengutronix.de>,
	Vasily Gorbik <gor@linux.ibm.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-alpha@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Stafford Horne <shorne@gmail.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Chris Zankel <chris@zankel.net>, Stephen Boyd <sboyd@kernel.org>,
	rh0@fb.com, dinguyen@kernel.org,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Joel Fernandes <joel@joelfernandes.org>,
	Fabio Estevam <festevam@gmail.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Kevin Hilman <khilman@kernel.or g>,
	linux-csky@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
	linux-snps-arc@lists.infradead.org, Mel Gorman <mgorman@suse.de>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Yury Norov <yury.norov@gmail.com>,
	ulli.kroll@googlemail.com, vgupta@kernel.org,
	linux-clk <linux-clk@vger.kernel.org>,
	Michal Simek <monstr@monstr.eu>,
	Steven Rostedt <rostedt@goodmis.org>,
	rcu@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
	bcain@quicinc.com,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Parisc List <linux-parisc@vger.kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Shawn Guo <shawnguo@kernel.org>,
	David Miller <davem@davemloft.net>, Rich Felker <dalias@libc.org>,
	Peter Zijlstra <peterz@infradead.org>,
	amakhalov@vmware.com,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-riscv <linux-riscv@lists.infradead.org>,
	anton.ivanov@cambridgegreys.com, jonas@southpole.se,
	Arnd Bergmann <arnd@arndb.de> ,
	Richard Weinberger <richard@nod.at>,
	the arch/x86 maintainers <x86@kernel.org>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Ingo Molnar <mingo@redhat.com>, Albert Ou <aou@eecs.berkeley.edu>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	stefan.kristiansson@saunalahti.fi, openrisc@lists.librecores.org,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	namhyung@kernel.org,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	jpoimboe@kernel.org, Juergen Gross <jgross@suse.com>,
	pv-drivers@vmware.com,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Anup Patel <anup@brainfault.org>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Johannes Berg <johannes@sipsolutions.net>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
Date: Sat, 30 Jul 2022 02:48:00 -0700	[thread overview]
Message-ID: <20220730094800.GB1587@lespinasse.org> (raw)
In-Reply-To: <CAJZ5v0gyPtX=ksCibo2ZN_BztCqUn9KRtRu+gsJ5KetB_1MwEQ@mail.gmail.com>

On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> <michel@lespinasse.org> wrote:
> >
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > > Xeons") wrecked intel_idle in two ways:
> > > > >
> > > > >  - must not have tracing in idle functions
> > > > >  - must return with IRQs disabled
> > > > >
> > > > > Additionally, it added a branch for no good reason.
> > > > >
> > > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > >
> > > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > > usage" when booting a kernel with debug options compiled in. Please
> > > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > > and is still present in v5.19-rc8.
> > > >
> > > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > >
> > > I finally got a chance to take a quick look at this.
> > >
> > > The rcu_eqs_exit() function is making a lockdep complaint about
> > > being invoked with interrupts enabled.  This function is called from
> > > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > > interrupts before invoking rcu_eqs_exit().
> > >
> > > The only other call to rcu_idle_exit() does not disable interrupts,
> > > but it is via rcu_user_exit(), which would be a very odd choice for
> > > cpuidle_enter_state().
> > >
> > > It seems unlikely, but it might be that it is the use of local_irq_save()
> > > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > > the trouble.  If this is the case, then the commit shown below would
> > > help.  Note that this commit removes the warning from lockdep, so it
> > > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > > equivalent debugging.
> > >
> > > Could you please try your test with the -rce commit shown below applied?
> >
> > Thanks for looking into it.
> >
> > After checking out Peter's commit 32d4fd5751ea,
> > cherry picking your commit ed4ae5eff4b3,
> > and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> > I am now seeing this a few seconds into the boot:
> >
> > [    3.010650] ------------[ cut here ]------------
> > [    3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 sched_clock_tick+0x27/0x60
> > [    3.010657] Modules linked in:
> > [    3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc1-test-00005-g1be22fea0611 #1
> > [    3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> > [    3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> > [    3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
> >  89 c0 48 03 1c c5 c0 98
> > [    3.010667] RSP: 0000:ffffffffb2803e28 EFLAGS: 00010002
> > [    3.010670] RAX: 0000000000000001 RBX: ffffc8ce7fa07060 RCX: 0000000000000001
> > [    3.010671] RDX: 0000000000000000 RSI: ffffffffb268dd21 RDI: ffffffffb269ab13
> > [    3.010673] RBP: 0000000000000001 R08: ffffffffffc300d5 R09: 000000000002be80
> > [    3.010674] R10: 000003625b53183a R11: ffffa012b802b7a4 R12: ffffffffb2aa9e80
> > [    3.010675] R13: ffffffffb2aa9e00 R14: 0000000000000001 R15: 0000000000000000
> > [    3.010677] FS:  0000000000000000(0000) GS:ffffa012b8000000(0000) knlGS:0000000000000000
> > [    3.010678] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    3.010680] CR2: ffffa012f81ff000 CR3: 0000000c99612001 CR4: 00000000003706f0
> > [    3.010681] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    3.010682] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [    3.010683] Call Trace:
> > [    3.010685]  <TASK>
> > [    3.010688]  cpuidle_enter_state+0xb7/0x4b0
> > [    3.010694]  cpuidle_enter+0x29/0x40
> > [    3.010697]  do_idle+0x1d4/0x210
> > [    3.010702]  cpu_startup_entry+0x19/0x20
> > [    3.010704]  rest_init+0x117/0x1a0
> > [    3.010708]  arch_call_rest_init+0xa/0x10
> > [    3.010711]  start_kernel+0x6d8/0x6ff
> > [    3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> > [    3.010728]  </TASK>
> > [    3.010729] irq event stamp: 44179
> > [    3.010730] hardirqs last  enabled at (44179): [<ffffffffb2000ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20
> > [    3.010734] hardirqs last disabled at (44177): [<ffffffffb22003f0>] __do_softirq+0x3f0/0x498
> > [    3.010736] softirqs last  enabled at (44178): [<ffffffffb2200332>] __do_softirq+0x332/0x498
> > [    3.010738] softirqs last disabled at (44171): [<ffffffffb16c760b>] irq_exit_rcu+0xab/0xf0
> > [    3.010741] ---[ end trace 0000000000000000 ]---
> 
> Can you please give this patch a go:
> https://patchwork.kernel.org/project/linux-pm/patch/Yt/AxPFi88neW7W5@e126311.manchester.arm.com/
> ?

I tried, but it didn't change the picture for me.

I'm not sure if that was the patch you meant to send though, as it
seems it's only adding a tracepoint so shouldn't make any difference
if I'm not actually using the tracepoint ?

WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <michel@lespinasse.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michel Lespinasse <michel@lespinasse.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	vgupta@kernel.org,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	ulli.kroll@googlemail.com,
	Linus Walleij <linus.walleij@linaro.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	bcain@quicinc.com, Huacai Chen <chenhuacai@kernel.org>,
	kernel@xen0n.name, Geert Uytterhoeven <geert@linux-m68k.org>,
	sammy@sammy.net, Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	dinguyen@kernel.org, jonas@southpole.se,
	stefan.kristiansson@saunalahti.fi,
	Stafford Horne <shorne@gmail.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, David Miller <davem@davemloft.net>,
	Richard Weinberger <richard@nod.at>,
	anton.ivanov@cambridgegreys.com,
	Johannes Berg <johannes@sipsolutions.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	acme@kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	jolsa@kernel.org, namhyung@kernel.org,
	Juergen Gross <jgross@suse.com>,
	srivatsa@csail.mit.edu, amakhalov@vmware.com,
	pv-drivers@vmware.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>, Len Brown <lenb@kernel.org>,
	Pavel Machek <pavel@ucw.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Anup Patel <anup@brainfault.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Arnd Bergmann <arnd@arndb.de>, Yury Norov <yury.norov@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Steven Rostedt <rostedt@goodmis.org>,
	Petr Mladek <pmladek@suse.com>,
	senozhatsky@chromium.org, John Ogness <john.ogness@linutronix.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	quic_neeraju@quicinc.com, Josh Triplett <josh@joshtriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Benjamin Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	vschneid@redhat.com, jpoimboe@kernel.org,
	linux-alpha@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-snps-arc@lists.infradead.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	openrisc@lists.librecores.org,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-s390@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, linux-xtensa@linux-xtensa.org,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	rcu@vger.kernel.org, rh0@fb.com
Subject: Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
Date: Sat, 30 Jul 2022 02:48:00 -0700	[thread overview]
Message-ID: <20220730094800.GB1587@lespinasse.org> (raw)
In-Reply-To: <CAJZ5v0gyPtX=ksCibo2ZN_BztCqUn9KRtRu+gsJ5KetB_1MwEQ@mail.gmail.com>

On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> <michel@lespinasse.org> wrote:
> >
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > > Xeons") wrecked intel_idle in two ways:
> > > > >
> > > > >  - must not have tracing in idle functions
> > > > >  - must return with IRQs disabled
> > > > >
> > > > > Additionally, it added a branch for no good reason.
> > > > >
> > > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > >
> > > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > > usage" when booting a kernel with debug options compiled in. Please
> > > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > > and is still present in v5.19-rc8.
> > > >
> > > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > >
> > > I finally got a chance to take a quick look at this.
> > >
> > > The rcu_eqs_exit() function is making a lockdep complaint about
> > > being invoked with interrupts enabled.  This function is called from
> > > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > > interrupts before invoking rcu_eqs_exit().
> > >
> > > The only other call to rcu_idle_exit() does not disable interrupts,
> > > but it is via rcu_user_exit(), which would be a very odd choice for
> > > cpuidle_enter_state().
> > >
> > > It seems unlikely, but it might be that it is the use of local_irq_save()
> > > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > > the trouble.  If this is the case, then the commit shown below would
> > > help.  Note that this commit removes the warning from lockdep, so it
> > > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > > equivalent debugging.
> > >
> > > Could you please try your test with the -rce commit shown below applied?
> >
> > Thanks for looking into it.
> >
> > After checking out Peter's commit 32d4fd5751ea,
> > cherry picking your commit ed4ae5eff4b3,
> > and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> > I am now seeing this a few seconds into the boot:
> >
> > [    3.010650] ------------[ cut here ]------------
> > [    3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 sched_clock_tick+0x27/0x60
> > [    3.010657] Modules linked in:
> > [    3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc1-test-00005-g1be22fea0611 #1
> > [    3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> > [    3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> > [    3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
> >  89 c0 48 03 1c c5 c0 98
> > [    3.010667] RSP: 0000:ffffffffb2803e28 EFLAGS: 00010002
> > [    3.010670] RAX: 0000000000000001 RBX: ffffc8ce7fa07060 RCX: 0000000000000001
> > [    3.010671] RDX: 0000000000000000 RSI: ffffffffb268dd21 RDI: ffffffffb269ab13
> > [    3.010673] RBP: 0000000000000001 R08: ffffffffffc300d5 R09: 000000000002be80
> > [    3.010674] R10: 000003625b53183a R11: ffffa012b802b7a4 R12: ffffffffb2aa9e80
> > [    3.010675] R13: ffffffffb2aa9e00 R14: 0000000000000001 R15: 0000000000000000
> > [    3.010677] FS:  0000000000000000(0000) GS:ffffa012b8000000(0000) knlGS:0000000000000000
> > [    3.010678] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    3.010680] CR2: ffffa012f81ff000 CR3: 0000000c99612001 CR4: 00000000003706f0
> > [    3.010681] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    3.010682] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [    3.010683] Call Trace:
> > [    3.010685]  <TASK>
> > [    3.010688]  cpuidle_enter_state+0xb7/0x4b0
> > [    3.010694]  cpuidle_enter+0x29/0x40
> > [    3.010697]  do_idle+0x1d4/0x210
> > [    3.010702]  cpu_startup_entry+0x19/0x20
> > [    3.010704]  rest_init+0x117/0x1a0
> > [    3.010708]  arch_call_rest_init+0xa/0x10
> > [    3.010711]  start_kernel+0x6d8/0x6ff
> > [    3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> > [    3.010728]  </TASK>
> > [    3.010729] irq event stamp: 44179
> > [    3.010730] hardirqs last  enabled at (44179): [<ffffffffb2000ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20
> > [    3.010734] hardirqs last disabled at (44177): [<ffffffffb22003f0>] __do_softirq+0x3f0/0x498
> > [    3.010736] softirqs last  enabled at (44178): [<ffffffffb2200332>] __do_softirq+0x332/0x498
> > [    3.010738] softirqs last disabled at (44171): [<ffffffffb16c760b>] irq_exit_rcu+0xab/0xf0
> > [    3.010741] ---[ end trace 0000000000000000 ]---
> 
> Can you please give this patch a go:
> https://patchwork.kernel.org/project/linux-pm/patch/Yt/AxPFi88neW7W5@e126311.manchester.arm.com/
> ?

I tried, but it didn't change the picture for me.

I'm not sure if that was the patch you meant to send though, as it
seems it's only adding a tracepoint so shouldn't make any difference
if I'm not actually using the tracepoint ?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <michel@lespinasse.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michel Lespinasse <michel@lespinasse.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	vgupta@kernel.org,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	ulli.kroll@googlemail.com,
	Linus Walleij <linus.walleij@linaro.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	bcain@quicinc.com, Huacai Chen <chenhuacai@kernel.org>,
	kernel@xen0n.name, Geert Uytterhoeven <geert@linux-m68k.org>,
	sammy@sammy.net, Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	dinguyen@kernel.org, jonas@southpole.se,
	stefan.kristiansson@saunalahti.fi,
	Stafford Horne <shorne@gmail.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, David Miller <davem@davemloft.net>,
	Richard Weinberger <richard@nod.at>,
	anton.ivanov@cambridgegreys.com,
	Johannes Berg <johannes@sipsolutions.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	acme@kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	jolsa@kernel.org, namhyung@kernel.org,
	Juergen Gross <jgross@suse.com>,
	srivatsa@csail.mit.edu, amakhalov@vmware.com,
	pv-drivers@vmware.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>, Len Brown <lenb@kernel.org>,
	Pavel Machek <pavel@ucw.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Anup Patel <anup@brainfault.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Arnd Bergmann <arnd@arndb.de>, Yury Norov <yury.norov@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Steven Rostedt <rostedt@goodmis.org>,
	Petr Mladek <pmladek@suse.com>,
	senozhatsky@chromium.org, John Ogness <john.ogness@linutronix.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	quic_neeraju@quicinc.com, Josh Triplett <josh@joshtriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Benjamin Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	vschneid@redhat.com, jpoimboe@kernel.org,
	linux-alpha@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-snps-arc@lists.infradead.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	openrisc@lists.librecores.org,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-s390@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, linux-xtensa@linux-xtensa.org,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	rcu@vger.kernel.org, rh0@fb.com
Subject: Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
Date: Sat, 30 Jul 2022 09:48:00 +0000	[thread overview]
Message-ID: <20220730094800.GB1587@lespinasse.org> (raw)
In-Reply-To: <CAJZ5v0gyPtX=ksCibo2ZN_BztCqUn9KRtRu+gsJ5KetB_1MwEQ@mail.gmail.com>

On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> <michel@lespinasse.org> wrote:
> >
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > > Xeons") wrecked intel_idle in two ways:
> > > > >
> > > > >  - must not have tracing in idle functions
> > > > >  - must return with IRQs disabled
> > > > >
> > > > > Additionally, it added a branch for no good reason.
> > > > >
> > > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > >
> > > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > > usage" when booting a kernel with debug options compiled in. Please
> > > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > > and is still present in v5.19-rc8.
> > > >
> > > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > >
> > > I finally got a chance to take a quick look at this.
> > >
> > > The rcu_eqs_exit() function is making a lockdep complaint about
> > > being invoked with interrupts enabled.  This function is called from
> > > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > > interrupts before invoking rcu_eqs_exit().
> > >
> > > The only other call to rcu_idle_exit() does not disable interrupts,
> > > but it is via rcu_user_exit(), which would be a very odd choice for
> > > cpuidle_enter_state().
> > >
> > > It seems unlikely, but it might be that it is the use of local_irq_save()
> > > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > > the trouble.  If this is the case, then the commit shown below would
> > > help.  Note that this commit removes the warning from lockdep, so it
> > > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > > equivalent debugging.
> > >
> > > Could you please try your test with the -rce commit shown below applied?
> >
> > Thanks for looking into it.
> >
> > After checking out Peter's commit 32d4fd5751ea,
> > cherry picking your commit ed4ae5eff4b3,
> > and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> > I am now seeing this a few seconds into the boot:
> >
> > [    3.010650] ------------[ cut here ]------------
> > [    3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 sched_clock_tick+0x27/0x60
> > [    3.010657] Modules linked in:
> > [    3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc1-test-00005-g1be22fea0611 #1
> > [    3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> > [    3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> > [    3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
> >  89 c0 48 03 1c c5 c0 98
> > [    3.010667] RSP: 0000:ffffffffb2803e28 EFLAGS: 00010002
> > [    3.010670] RAX: 0000000000000001 RBX: ffffc8ce7fa07060 RCX: 0000000000000001
> > [    3.010671] RDX: 0000000000000000 RSI: ffffffffb268dd21 RDI: ffffffffb269ab13
> > [    3.010673] RBP: 0000000000000001 R08: ffffffffffc300d5 R09: 000000000002be80
> > [    3.010674] R10: 000003625b53183a R11: ffffa012b802b7a4 R12: ffffffffb2aa9e80
> > [    3.010675] R13: ffffffffb2aa9e00 R14: 0000000000000001 R15: 0000000000000000
> > [    3.010677] FS:  0000000000000000(0000) GS:ffffa012b8000000(0000) knlGS:0000000000000000
> > [    3.010678] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    3.010680] CR2: ffffa012f81ff000 CR3: 0000000c99612001 CR4: 00000000003706f0
> > [    3.010681] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    3.010682] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [    3.010683] Call Trace:
> > [    3.010685]  <TASK>
> > [    3.010688]  cpuidle_enter_state+0xb7/0x4b0
> > [    3.010694]  cpuidle_enter+0x29/0x40
> > [    3.010697]  do_idle+0x1d4/0x210
> > [    3.010702]  cpu_startup_entry+0x19/0x20
> > [    3.010704]  rest_init+0x117/0x1a0
> > [    3.010708]  arch_call_rest_init+0xa/0x10
> > [    3.010711]  start_kernel+0x6d8/0x6ff
> > [    3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> > [    3.010728]  </TASK>
> > [    3.010729] irq event stamp: 44179
> > [    3.010730] hardirqs last  enabled at (44179): [<ffffffffb2000ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20
> > [    3.010734] hardirqs last disabled at (44177): [<ffffffffb22003f0>] __do_softirq+0x3f0/0x498
> > [    3.010736] softirqs last  enabled at (44178): [<ffffffffb2200332>] __do_softirq+0x332/0x498
> > [    3.010738] softirqs last disabled at (44171): [<ffffffffb16c760b>] irq_exit_rcu+0xab/0xf0
> > [    3.010741] ---[ end trace 0000000000000000 ]---
> 
> Can you please give this patch a go:
> https://patchwork.kernel.org/project/linux-pm/patch/Yt/AxPFi88neW7W5@e126311.manchester.arm.com/
> ?

I tried, but it didn't change the picture for me.

I'm not sure if that was the patch you meant to send though, as it
seems it's only adding a tracepoint so shouldn't make any difference
if I'm not actually using the tracepoint ?

WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <michel@lespinasse.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michel Lespinasse <michel@lespinasse.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	vgupta@kernel.org,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	ulli.kroll@googlemail.com,
	Linus Walleij <linus.walleij@linaro.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Sascha Hauer <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	bcain@quicinc.com, Huaca
Subject: Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
Date: Sat, 30 Jul 2022 02:48:00 -0700	[thread overview]
Message-ID: <20220730094800.GB1587@lespinasse.org> (raw)
In-Reply-To: <CAJZ5v0gyPtX=ksCibo2ZN_BztCqUn9KRtRu+gsJ5KetB_1MwEQ@mail.gmail.com>

On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> <michel@lespinasse.org> wrote:
> >
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > > Xeons") wrecked intel_idle in two ways:
> > > > >
> > > > >  - must not have tracing in idle functions
> > > > >  - must return with IRQs disabled
> > > > >
> > > > > Additionally, it added a branch for no good reason.
> > > > >
> > > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > >
> > > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > > usage" when booting a kernel with debug options compiled in. Please
> > > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > > and is still present in v5.19-rc8.
> > > >
> > > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > >
> > > I finally got a chance to take a quick look at this.
> > >
> > > The rcu_eqs_exit() function is making a lockdep complaint about
> > > being invoked with interrupts enabled.  This function is called from
> > > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > > interrupts before invoking rcu_eqs_exit().
> > >
> > > The only other call to rcu_idle_exit() does not disable interrupts,
> > > but it is via rcu_user_exit(), which would be a very odd choice for
> > > cpuidle_enter_state().
> > >
> > > It seems unlikely, but it might be that it is the use of local_irq_save()
> > > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > > the trouble.  If this is the case, then the commit shown below would
> > > help.  Note that this commit removes the warning from lockdep, so it
> > > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > > equivalent debugging.
> > >
> > > Could you please try your test with the -rce commit shown below applied?
> >
> > Thanks for looking into it.
> >
> > After checking out Peter's commit 32d4fd5751ea,
> > cherry picking your commit ed4ae5eff4b3,
> > and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> > I am now seeing this a few seconds into the boot:
> >
> > [    3.010650] ------------[ cut here ]------------
> > [    3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 sched_clock_tick+0x27/0x60
> > [    3.010657] Modules linked in:
> > [    3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc1-test-00005-g1be22fea0611 #1
> > [    3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> > [    3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> > [    3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
> >  89 c0 48 03 1c c5 c0 98
> > [    3.010667] RSP: 0000:ffffffffb2803e28 EFLAGS: 00010002
> > [    3.010670] RAX: 0000000000000001 RBX: ffffc8ce7fa07060 RCX: 0000000000000001
> > [    3.010671] RDX: 0000000000000000 RSI: ffffffffb268dd21 RDI: ffffffffb269ab13
> > [    3.010673] RBP: 0000000000000001 R08: ffffffffffc300d5 R09: 000000000002be80
> > [    3.010674] R10: 000003625b53183a R11: ffffa012b802b7a4 R12: ffffffffb2aa9e80
> > [    3.010675] R13: ffffffffb2aa9e00 R14: 0000000000000001 R15: 0000000000000000
> > [    3.010677] FS:  0000000000000000(0000) GS:ffffa012b8000000(0000) knlGS:0000000000000000
> > [    3.010678] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    3.010680] CR2: ffffa012f81ff000 CR3: 0000000c99612001 CR4: 00000000003706f0
> > [    3.010681] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [    3.010682] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [    3.010683] Call Trace:
> > [    3.010685]  <TASK>
> > [    3.010688]  cpuidle_enter_state+0xb7/0x4b0
> > [    3.010694]  cpuidle_enter+0x29/0x40
> > [    3.010697]  do_idle+0x1d4/0x210
> > [    3.010702]  cpu_startup_entry+0x19/0x20
> > [    3.010704]  rest_init+0x117/0x1a0
> > [    3.010708]  arch_call_rest_init+0xa/0x10
> > [    3.010711]  start_kernel+0x6d8/0x6ff
> > [    3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> > [    3.010728]  </TASK>
> > [    3.010729] irq event stamp: 44179
> > [    3.010730] hardirqs last  enabled at (44179): [<ffffffffb2000ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20
> > [    3.010734] hardirqs last disabled at (44177): [<ffffffffb22003f0>] __do_softirq+0x3f0/0x498
> > [    3.010736] softirqs last  enabled at (44178): [<ffffffffb2200332>] __do_softirq+0x332/0x498
> > [    3.010738] softirqs last disabled at (44171): [<ffffffffb16c760b>] irq_exit_rcu+0xab/0xf0
> > [    3.010741] ---[ end trace 0000000000000000 ]---
> 
> Can you please give this patch a go:
> https://patchwork.kernel.org/project/linux-pm/patch/Yt/AxPFi88neW7W5@e126311.manchester.arm.com/
> ?

I tried, but it didn't change the picture for me.

I'm not sure if that was the patch you meant to send though, as it
seems it's only adding a tracepoint so shouldn't make any difference
if I'm not actually using the tracepoint ?

  reply	other threads:[~2022-07-30  9:48 UTC|newest]

Thread overview: 820+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 14:27 [PATCH 00/36] cpuidle,rcu: Cleanup the mess Peter Zijlstra
2022-06-08 14:27 ` Peter Zijlstra
2022-06-08 14:27 ` Peter Zijlstra
2022-06-08 14:27 ` Peter Zijlstra
2022-06-08 14:27 ` Peter Zijlstra
2022-06-08 14:27 ` Peter Zijlstra
2022-06-08 14:27 ` Peter Zijlstra
2022-06-08 14:27 ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 01/36] x86/perf/amd: Remove tracing from perf_lopwr_cb() Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 02/36] x86/idle: Replace x86_idle with a static_call Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 18:13   ` Rafael J. Wysocki
2022-06-08 18:13     ` Rafael J. Wysocki
2022-06-08 18:13     ` Rafael J. Wysocki
2022-06-08 18:13     ` Rafael J. Wysocki
2022-06-08 18:13     ` Rafael J. Wysocki
2022-06-08 18:13     ` Rafael J. Wysocki
2022-06-08 18:13     ` Rafael J. Wysocki
2022-06-08 18:13     ` Rafael J. Wysocki
2022-06-08 14:27 ` [PATCH 03/36] cpuidle/poll: Ensure IRQ state is invariant Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-07-06 13:51   ` Rafael J. Wysocki
2022-07-06 13:51     ` Rafael J. Wysocki
2022-07-06 13:51     ` Rafael J. Wysocki
2022-07-06 13:51     ` Rafael J. Wysocki
2022-07-06 13:51     ` Rafael J. Wysocki
2022-07-06 13:51     ` Rafael J. Wysocki
2022-07-06 13:51     ` Rafael J. Wysocki
2022-07-06 13:51     ` Rafael J. Wysocki
2022-06-08 14:27 ` [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 15:01   ` Rafael J. Wysocki
2022-06-08 15:01     ` Rafael J. Wysocki
2022-06-08 15:01     ` Rafael J. Wysocki
2022-06-08 15:01     ` Rafael J. Wysocki
2022-06-08 15:01     ` Rafael J. Wysocki
2022-06-08 15:01     ` Rafael J. Wysocki
2022-06-08 15:01     ` Rafael J. Wysocki
2022-06-08 15:01     ` Rafael J. Wysocki
2022-06-08 15:01     ` Rafael J. Wysocki
2022-06-08 15:48     ` Peter Zijlstra
2022-06-08 15:48       ` Peter Zijlstra
2022-06-08 15:48       ` Peter Zijlstra
2022-06-08 15:48       ` Peter Zijlstra
2022-06-08 15:48       ` Peter Zijlstra
2022-06-08 15:48       ` Peter Zijlstra
2022-06-08 15:48       ` Peter Zijlstra
2022-06-08 15:48       ` Peter Zijlstra
2022-06-08 16:08       ` Rafael J. Wysocki
2022-06-08 16:08         ` Rafael J. Wysocki
2022-06-08 16:08         ` Rafael J. Wysocki
2022-06-08 16:08         ` Rafael J. Wysocki
2022-06-08 16:08         ` Rafael J. Wysocki
2022-06-08 16:08         ` Rafael J. Wysocki
2022-06-08 16:08         ` Rafael J. Wysocki
2022-06-08 16:08         ` Rafael J. Wysocki
2022-06-08 16:08         ` Rafael J. Wysocki
2022-06-09 23:49   ` Jacob Pan
2022-06-09 23:49     ` Jacob Pan
2022-06-09 23:49     ` Jacob Pan
2022-06-09 23:49     ` Jacob Pan
2022-06-09 23:49     ` Jacob Pan
2022-06-09 23:49     ` Jacob Pan
2022-06-09 23:49     ` Jacob Pan
2022-06-13  8:44     ` Peter Zijlstra
2022-06-13  8:44       ` Peter Zijlstra
2022-06-13  8:44       ` Peter Zijlstra
2022-06-13  8:44       ` Peter Zijlstra
2022-06-13  8:44       ` Peter Zijlstra
2022-06-13  8:44       ` Peter Zijlstra
2022-06-13  8:44       ` Peter Zijlstra
2022-06-13  8:44       ` Peter Zijlstra
2022-06-16 21:26       ` Jacob Pan
2022-06-16 21:26         ` Jacob Pan
2022-06-16 21:26         ` Jacob Pan
2022-06-16 21:26         ` Jacob Pan
2022-06-16 21:26         ` Jacob Pan
2022-06-16 21:26         ` Jacob Pan
2022-06-16 21:26         ` Jacob Pan
2022-07-25 19:43   ` Michel Lespinasse
2022-07-25 19:43     ` Michel Lespinasse
2022-07-25 19:43     ` Michel Lespinasse
2022-07-25 19:43     ` Michel Lespinasse
2022-07-25 19:43     ` Michel Lespinasse
2022-07-25 19:43     ` Michel Lespinasse
2022-07-25 19:43     ` Michel Lespinasse
2022-07-28 17:20     ` Paul E. McKenney
2022-07-28 17:20       ` Paul E. McKenney
2022-07-28 17:20       ` Paul E. McKenney
2022-07-28 17:20       ` Paul E. McKenney
2022-07-28 17:20       ` Paul E. McKenney
2022-07-28 17:20       ` Paul E. McKenney
2022-07-28 17:20       ` Paul E. McKenney
2022-07-29 10:24       ` Michel Lespinasse
2022-07-29 10:24         ` Michel Lespinasse
2022-07-29 10:24         ` Michel Lespinasse
2022-07-29 10:24         ` Michel Lespinasse
2022-07-29 10:24         ` Michel Lespinasse
2022-07-29 10:24         ` Michel Lespinasse
2022-07-29 10:24         ` Michel Lespinasse
2022-07-29 14:59         ` Rafael J. Wysocki
2022-07-29 14:59           ` Rafael J. Wysocki
2022-07-29 14:59           ` Rafael J. Wysocki
2022-07-29 14:59           ` Rafael J. Wysocki
2022-07-29 14:59           ` Rafael J. Wysocki
2022-07-29 14:59           ` Rafael J. Wysocki
2022-07-29 14:59           ` Rafael J. Wysocki
2022-07-29 14:59           ` Rafael J. Wysocki
2022-07-30  9:48           ` Michel Lespinasse [this message]
2022-07-30  9:48             ` Michel Lespinasse
2022-07-30  9:48             ` Michel Lespinasse
2022-07-30  9:48             ` Michel Lespinasse
2022-07-30  9:48             ` Michel Lespinasse
2022-07-30  9:48             ` Michel Lespinasse
2022-07-30  9:48             ` Michel Lespinasse
2022-07-30 19:52             ` Rafael J. Wysocki
2022-07-30 19:52               ` Rafael J. Wysocki
2022-07-30 19:52               ` Rafael J. Wysocki
2022-07-30 19:52               ` Rafael J. Wysocki
2022-07-30 19:52               ` Rafael J. Wysocki
2022-07-30 19:52               ` Rafael J. Wysocki
2022-07-30 19:52               ` Rafael J. Wysocki
2022-07-30 19:52               ` Rafael J. Wysocki
2022-07-30 23:45               ` Michel Lespinasse
2022-07-30 23:45                 ` Michel Lespinasse
2022-07-30 23:45                 ` Michel Lespinasse
2022-07-30 23:45                 ` Michel Lespinasse
2022-07-30 23:45                 ` Michel Lespinasse
2022-07-30 23:45                 ` Michel Lespinasse
2022-07-30 23:45                 ` Michel Lespinasse
2022-07-29 15:26         ` Paul E. McKenney
2022-07-29 15:26           ` Paul E. McKenney
2022-07-29 15:26           ` Paul E. McKenney
2022-07-29 15:26           ` Paul E. McKenney
2022-07-29 15:26           ` Paul E. McKenney
2022-07-29 15:26           ` Paul E. McKenney
2022-07-29 15:26           ` Paul E. McKenney
2022-07-29 15:28           ` Paul E. McKenney
2022-07-29 15:28             ` Paul E. McKenney
2022-07-29 15:28             ` Paul E. McKenney
2022-07-29 15:28             ` Paul E. McKenney
2022-07-29 15:28             ` Paul E. McKenney
2022-07-29 15:28             ` Paul E. McKenney
2022-07-29 15:28             ` Paul E. McKenney
2022-07-30  9:40           ` Michel Lespinasse
2022-07-30  9:40             ` Michel Lespinasse
2022-07-30  9:40             ` Michel Lespinasse
2022-07-30  9:40             ` Michel Lespinasse
2022-07-30  9:40             ` Michel Lespinasse
2022-07-30  9:40             ` Michel Lespinasse
2022-07-30  9:40             ` Michel Lespinasse
2022-07-30 18:16             ` Paul E. McKenney
2022-07-30 18:16               ` Paul E. McKenney
2022-07-30 18:16               ` Paul E. McKenney
2022-07-30 18:16               ` Paul E. McKenney
2022-07-30 18:16               ` Paul E. McKenney
2022-07-30 18:16               ` Paul E. McKenney
2022-07-30 18:16               ` Paul E. McKenney
2022-06-08 14:27 ` [PATCH 05/36] cpuidle: Move IRQ state validation Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-07-06 13:54   ` Rafael J. Wysocki
2022-07-06 13:54     ` Rafael J. Wysocki
2022-07-06 13:54     ` Rafael J. Wysocki
2022-07-06 13:54     ` Rafael J. Wysocki
2022-07-06 13:54     ` Rafael J. Wysocki
2022-07-06 13:54     ` Rafael J. Wysocki
2022-07-06 13:54     ` Rafael J. Wysocki
2022-07-06 13:54     ` Rafael J. Wysocki
2022-06-08 14:27 ` [PATCH 06/36] cpuidle,riscv: Push RCU-idle into driver Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 07/36] cpuidle,tegra: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 08/36] cpuidle,psci: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 09/36] cpuidle,imx6: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 10/36] cpuidle,omap3: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-13 12:33   ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-08 14:27 ` [PATCH 11/36] cpuidle,armada: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 12/36] cpuidle,omap2: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-13 12:33   ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-13 12:33     ` Tony Lindgren
2022-06-08 14:27 ` [PATCH 13/36] cpuidle,dt: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 14/36] cpuidle: Fix rcu_idle_*() usage Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-14 12:41   ` Mark Rutland
2022-06-14 12:41     ` Mark Rutland
2022-06-14 12:41     ` Mark Rutland
2022-06-14 12:41     ` Mark Rutland
2022-06-14 12:41     ` Mark Rutland
2022-06-14 12:41     ` Mark Rutland
2022-06-14 12:41     ` Mark Rutland
2022-06-14 12:41     ` Mark Rutland
2022-06-14 12:41     ` Mark Rutland
2022-06-14 16:40     ` Peter Zijlstra
2022-06-14 16:40       ` Peter Zijlstra
2022-06-14 16:40       ` Peter Zijlstra
2022-06-14 16:40       ` Peter Zijlstra
2022-06-14 16:40       ` Peter Zijlstra
2022-06-14 16:40       ` Peter Zijlstra
2022-06-14 16:40       ` Peter Zijlstra
2022-06-14 16:40       ` Peter Zijlstra
2022-06-14 16:59       ` Mark Rutland
2022-06-14 16:59         ` Mark Rutland
2022-06-14 16:59         ` Mark Rutland
2022-06-14 16:59         ` Mark Rutland
2022-06-14 16:59         ` Mark Rutland
2022-06-14 16:59         ` Mark Rutland
2022-06-14 16:59         ` Mark Rutland
2022-06-14 16:59         ` Mark Rutland
2022-07-26  9:55   ` Gautham R. Shenoy
2022-07-26  9:56     ` Gautham R. Shenoy
2022-07-26  9:56     ` Gautham R. Shenoy
2022-07-26  9:56     ` Gautham R. Shenoy
2022-07-26  9:56     ` Gautham R. Shenoy
2022-07-26  9:56     ` Gautham R. Shenoy
2022-07-26  9:56     ` Gautham R. Shenoy
2022-06-08 14:27 ` [PATCH 15/36] cpuidle,cpu_pm: Remove RCU fiddling from cpu_pm_{enter,exit}() Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` [PATCH 15/36] cpuidle, cpu_pm: Remove RCU fiddling from cpu_pm_{enter, exit}() Peter Zijlstra
2022-06-08 14:27   ` [PATCH 15/36] cpuidle,cpu_pm: Remove RCU fiddling from cpu_pm_{enter,exit}() Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` [PATCH 15/36] cpuidle, cpu_pm: Remove RCU fiddling from cpu_pm_{enter, exit}() Peter Zijlstra
2022-06-14 16:13   ` [PATCH 15/36] cpuidle,cpu_pm: Remove RCU fiddling from cpu_pm_{enter,exit}() Mark Rutland
2022-06-14 16:13     ` Mark Rutland
2022-06-14 16:13     ` Mark Rutland
2022-06-14 16:13     ` Mark Rutland
2022-06-14 16:13     ` Mark Rutland
2022-06-14 16:13     ` Mark Rutland
2022-06-14 16:13     ` Mark Rutland
2022-06-14 16:13     ` Mark Rutland
2022-06-14 16:42     ` Peter Zijlstra
2022-06-14 16:42       ` Peter Zijlstra
2022-06-14 16:42       ` Peter Zijlstra
2022-06-14 16:42       ` Peter Zijlstra
2022-06-14 16:42       ` Peter Zijlstra
2022-06-14 16:42       ` Peter Zijlstra
2022-06-14 16:42       ` Peter Zijlstra
2022-06-14 16:42       ` Peter Zijlstra
2022-06-14 16:53       ` Mark Rutland
2022-06-14 16:53         ` Mark Rutland
2022-06-14 16:53         ` Mark Rutland
2022-06-14 16:53         ` Mark Rutland
2022-06-14 16:53         ` Mark Rutland
2022-06-14 16:53         ` Mark Rutland
2022-06-14 16:53         ` Mark Rutland
2022-06-14 16:53         ` Mark Rutland
2022-06-08 14:27 ` [PATCH 16/36] rcu: Fix rcu_idle_exit() Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-14 16:14   ` Mark Rutland
2022-06-14 16:14     ` Mark Rutland
2022-06-14 16:14     ` Mark Rutland
2022-06-14 16:14     ` Mark Rutland
2022-06-14 16:14     ` Mark Rutland
2022-06-14 16:14     ` Mark Rutland
2022-06-14 16:14     ` Mark Rutland
2022-06-14 16:14     ` Mark Rutland
2022-06-15  0:44   ` Paul E. McKenney
2022-06-15  0:44     ` Paul E. McKenney
2022-06-15  0:44     ` Paul E. McKenney
2022-06-15  0:44     ` Paul E. McKenney
2022-06-15  0:44     ` Paul E. McKenney
2022-06-15  0:44     ` Paul E. McKenney
2022-06-15  0:44     ` Paul E. McKenney
2022-06-08 14:27 ` [PATCH 17/36] acpi_idle: Remove tracing Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-07-06 13:59   ` Rafael J. Wysocki
2022-07-06 13:59     ` Rafael J. Wysocki
2022-07-06 13:59     ` Rafael J. Wysocki
2022-07-06 13:59     ` Rafael J. Wysocki
2022-07-06 13:59     ` Rafael J. Wysocki
2022-07-06 13:59     ` Rafael J. Wysocki
2022-07-06 13:59     ` Rafael J. Wysocki
2022-07-06 13:59     ` Rafael J. Wysocki
2022-06-08 14:27 ` [PATCH 18/36] cpuidle: Annotate poll_idle() Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-07-06 13:59   ` Rafael J. Wysocki
2022-07-06 14:00     ` Rafael J. Wysocki
2022-07-06 14:00     ` Rafael J. Wysocki
2022-07-06 14:00     ` Rafael J. Wysocki
2022-07-06 14:00     ` Rafael J. Wysocki
2022-07-06 14:00     ` Rafael J. Wysocki
2022-07-06 14:00     ` Rafael J. Wysocki
2022-07-06 14:00     ` Rafael J. Wysocki
2022-06-08 14:27 ` [PATCH 19/36] objtool/idle: Validate __cpuidle code as noinstr Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-07-06  9:46   ` Geert Uytterhoeven
2022-07-06  9:46     ` Geert Uytterhoeven
2022-07-06  9:46     ` Geert Uytterhoeven
2022-07-06  9:46     ` Geert Uytterhoeven
2022-07-06  9:46     ` Geert Uytterhoeven
2022-07-06  9:46     ` Geert Uytterhoeven
2022-07-06  9:46     ` Geert Uytterhoeven
2022-07-06  9:46     ` Geert Uytterhoeven
2022-06-08 14:27 ` [PATCH 20/36] arch/idle: Change arch_cpu_idle() IRQ behaviour Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 16:22   ` Arnd Bergmann
2022-06-08 16:22     ` Arnd Bergmann
2022-06-08 16:22     ` Arnd Bergmann
2022-06-08 16:22     ` Arnd Bergmann
2022-06-08 16:22     ` Arnd Bergmann
2022-06-08 16:22     ` Arnd Bergmann
2022-06-08 16:22     ` Arnd Bergmann
2022-06-08 16:22     ` Arnd Bergmann
2022-06-14 16:22   ` Mark Rutland
2022-06-14 16:22     ` Mark Rutland
2022-06-14 16:22     ` Mark Rutland
2022-06-14 16:22     ` Mark Rutland
2022-06-14 16:22     ` Mark Rutland
2022-06-14 16:22     ` Mark Rutland
2022-06-14 16:22     ` Mark Rutland
2022-06-14 16:22     ` Mark Rutland
2022-07-06 14:02   ` Rafael J. Wysocki
2022-07-06 14:02     ` Rafael J. Wysocki
2022-07-06 14:02     ` Rafael J. Wysocki
2022-07-06 14:02     ` Rafael J. Wysocki
2022-07-06 14:02     ` Rafael J. Wysocki
2022-07-06 14:02     ` Rafael J. Wysocki
2022-07-06 14:02     ` Rafael J. Wysocki
2022-07-06 14:02     ` Rafael J. Wysocki
2022-06-08 14:27 ` [PATCH 21/36] x86/tdx: Remove TDX_HCALL_ISSUE_STI Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-13  8:26   ` Lai Jiangshan
2022-06-13  8:26     ` Lai Jiangshan
2022-06-13  8:26     ` Lai Jiangshan
2022-06-13  8:26     ` Lai Jiangshan
2022-06-13  8:26     ` Lai Jiangshan
2022-06-13  8:26     ` Lai Jiangshan
2022-06-13  8:26     ` Lai Jiangshan
2022-06-13  8:41     ` Peter Zijlstra
2022-06-13  8:41       ` Peter Zijlstra
2022-06-13  8:41       ` Peter Zijlstra
2022-06-13  8:41       ` Peter Zijlstra
2022-06-13  8:41       ` Peter Zijlstra
2022-06-13  8:41       ` Peter Zijlstra
2022-06-13  8:41       ` Peter Zijlstra
2022-06-13  8:41       ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 22/36] arm,smp: Remove trace_.*_rcuidle() usage Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 23/36] arm64,smp: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-14 16:24   ` Mark Rutland
2022-06-14 16:24     ` Mark Rutland
2022-06-14 16:24     ` Mark Rutland
2022-06-14 16:24     ` Mark Rutland
2022-06-14 16:24     ` Mark Rutland
2022-06-14 16:24     ` Mark Rutland
2022-06-14 16:24     ` Mark Rutland
2022-06-14 16:24     ` Mark Rutland
2022-06-15  6:05     ` Marc Zyngier
2022-06-15  6:05       ` Marc Zyngier
2022-06-15  6:05       ` Marc Zyngier
2022-06-15  6:05       ` Marc Zyngier
2022-06-15  6:05       ` Marc Zyngier
2022-06-15  6:05       ` Marc Zyngier
2022-06-15  6:05       ` Marc Zyngier
2022-06-08 14:27 ` [PATCH 24/36] printk: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-09  9:16   ` Petr Mladek
2022-06-09  9:16     ` Petr Mladek
2022-06-09  9:16     ` Petr Mladek
2022-06-09  9:16     ` Petr Mladek
2022-06-09  9:16     ` Petr Mladek
2022-06-09  9:16     ` Petr Mladek via Virtualization
2022-06-09 10:02     ` Peter Zijlstra
2022-06-09 10:02       ` Peter Zijlstra
2022-06-09 10:02       ` Peter Zijlstra
2022-06-09 10:02       ` Peter Zijlstra
2022-06-09 10:02       ` Peter Zijlstra
2022-06-09 10:02       ` Peter Zijlstra
2022-06-09 10:02       ` Peter Zijlstra
2022-06-09 10:02       ` Peter Zijlstra
2022-06-09 11:30       ` Sergey Senozhatsky
2022-06-09 11:30         ` Sergey Senozhatsky
2022-06-09 11:30         ` Sergey Senozhatsky
2022-06-09 11:30         ` Sergey Senozhatsky
2022-06-09 11:30         ` Sergey Senozhatsky
2022-06-09 11:30         ` Sergey Senozhatsky
2022-06-09 11:30         ` Sergey Senozhatsky
2022-06-09 13:02         ` Petr Mladek
2022-06-09 13:02           ` Petr Mladek
2022-06-09 13:02           ` Petr Mladek
2022-06-09 13:02           ` Petr Mladek
2022-06-09 13:02           ` Petr Mladek
2022-06-09 13:02           ` Petr Mladek
2022-06-09 13:02           ` Petr Mladek via Virtualization
2022-06-09 13:02           ` Petr Mladek
2022-06-11  2:33           ` Sergey Senozhatsky
2022-06-11  2:33             ` Sergey Senozhatsky
2022-06-11  2:33             ` Sergey Senozhatsky
2022-06-11  2:33             ` Sergey Senozhatsky
2022-06-11  2:33             ` Sergey Senozhatsky
2022-06-11  2:33             ` Sergey Senozhatsky
2022-06-11  2:33             ` Sergey Senozhatsky
2022-06-14 14:37           ` Steven Rostedt
2022-06-14 14:37             ` Steven Rostedt
2022-06-14 14:37             ` Steven Rostedt
2022-06-14 14:37             ` Steven Rostedt
2022-06-14 14:37             ` Steven Rostedt
2022-06-14 14:37             ` Steven Rostedt
2022-06-14 14:37             ` Steven Rostedt
2022-06-14 14:37             ` Steven Rostedt
2022-06-09 13:06       ` Petr Mladek
2022-06-09 13:06         ` Petr Mladek
2022-06-09 13:06         ` Petr Mladek
2022-06-09 13:06         ` Petr Mladek
2022-06-09 13:06         ` Petr Mladek
2022-06-09 13:06         ` Petr Mladek
2022-06-09 13:06         ` Petr Mladek via Virtualization
2022-06-09 13:06         ` Petr Mladek
2022-06-11  2:23         ` Sergey Senozhatsky
2022-06-11  2:23           ` Sergey Senozhatsky
2022-06-11  2:23           ` Sergey Senozhatsky
2022-06-11  2:23           ` Sergey Senozhatsky
2022-06-11  2:23           ` Sergey Senozhatsky
2022-06-11  2:23           ` Sergey Senozhatsky
2022-06-11  2:23           ` Sergey Senozhatsky
2022-06-09 10:14   ` Petr Mladek
2022-06-09 10:14     ` Petr Mladek
2022-06-09 10:14     ` Petr Mladek
2022-06-09 10:14     ` Petr Mladek
2022-06-09 10:14     ` Petr Mladek
2022-06-09 10:14     ` Petr Mladek via Virtualization
2022-06-08 14:27 ` [PATCH 25/36] time/tick-broadcast: Remove RCU_NONIDLE usage Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-14 16:28   ` Mark Rutland
2022-06-14 16:28     ` Mark Rutland
2022-06-14 16:28     ` Mark Rutland
2022-06-14 16:28     ` Mark Rutland
2022-06-14 16:28     ` Mark Rutland
2022-06-14 16:28     ` Mark Rutland
2022-06-14 16:28     ` Mark Rutland
2022-06-14 16:28     ` Mark Rutland
2022-06-08 14:27 ` [PATCH 26/36] cpuidle,sched: Remove annotations from TIF_{POLLING_NRFLAG,NEED_RESCHED} Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` [PATCH 26/36] cpuidle, sched: Remove annotations from TIF_{POLLING_NRFLAG, NEED_RESCHED} Peter Zijlstra
2022-06-08 14:27   ` [PATCH 26/36] cpuidle,sched: Remove annotations from TIF_{POLLING_NRFLAG,NEED_RESCHED} Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` [PATCH 26/36] cpuidle, sched: Remove annotations from TIF_{POLLING_NRFLAG, NEED_RESCHED} Peter Zijlstra
2022-06-08 14:27 ` [PATCH 27/36] cpuidle,mwait: Make noinstr clean Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 28/36] cpuidle,tdx: Make tdx " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 29/36] cpuidle,xenpv: Make more PARAVIRT_XXL " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-13 18:48   ` Srivatsa S. Bhat
2022-06-13 18:48     ` [PATCH 29/36] cpuidle, xenpv: " Srivatsa S. Bhat
2022-06-13 18:48     ` [PATCH 29/36] cpuidle,xenpv: " Srivatsa S. Bhat
2022-06-13 18:48     ` Srivatsa S. Bhat
2022-06-13 18:48     ` [PATCH 29/36] cpuidle, xenpv: " Srivatsa S. Bhat
2022-06-13 18:48     ` [PATCH 29/36] cpuidle,xenpv: " Srivatsa S. Bhat
2022-06-13 18:48     ` Srivatsa S. Bhat
2022-06-13 18:48     ` [PATCH 29/36] cpuidle, xenpv: " Srivatsa S. Bhat
2022-06-13 19:23     ` [Pv-drivers] " Nadav Amit
2022-06-13 19:23       ` Nadav Amit via Virtualization
2022-06-13 19:23       ` Nadav Amit
2022-06-13 19:23       ` Nadav Amit
2022-06-13 19:23       ` Nadav Amit
2022-06-13 19:23       ` Nadav Amit
2022-06-13 19:23       ` Nadav Amit
2022-06-13 19:23       ` Nadav Amit
2022-06-13 19:23       ` Nadav Amit via Virtualization
2022-06-14 16:44       ` Peter Zijlstra
2022-06-14 16:44         ` Peter Zijlstra
2022-06-14 16:44         ` Peter Zijlstra
2022-06-14 16:44         ` Peter Zijlstra
2022-06-14 16:44         ` Peter Zijlstra
2022-06-14 16:44         ` Peter Zijlstra
2022-06-14 16:44         ` Peter Zijlstra
2022-06-14 16:44         ` Peter Zijlstra
2022-06-14 16:44         ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 30/36] cpuidle,nospec: Make " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 31/36] cpuidle,acpi: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-07-06 14:04   ` Rafael J. Wysocki
2022-07-06 14:04     ` Rafael J. Wysocki
2022-07-06 14:04     ` Rafael J. Wysocki
2022-07-06 14:04     ` Rafael J. Wysocki
2022-07-06 14:04     ` Rafael J. Wysocki
2022-07-06 14:04     ` Rafael J. Wysocki
2022-07-06 14:04     ` Rafael J. Wysocki
2022-07-06 14:04     ` Rafael J. Wysocki
2022-06-08 14:27 ` [PATCH 32/36] ftrace: WARN on rcuidle Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 33/36] cpuidle,omap3: Use WFI for omap3_pm_idle() Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 16:28   ` Arnd Bergmann
2022-06-08 16:28     ` Arnd Bergmann
2022-06-08 16:28     ` Arnd Bergmann
2022-06-08 16:28     ` Arnd Bergmann
2022-06-08 16:28     ` Arnd Bergmann
2022-06-08 16:28     ` Arnd Bergmann
2022-06-08 16:28     ` Arnd Bergmann
2022-06-08 16:28     ` Arnd Bergmann
2022-06-09  7:39     ` Tony Lindgren
2022-06-09  7:39       ` Tony Lindgren
2022-06-09  7:39       ` Tony Lindgren
2022-06-09  7:39       ` Tony Lindgren
2022-06-09  7:39       ` Tony Lindgren
2022-06-09  7:39       ` Tony Lindgren
2022-06-09  7:39       ` Tony Lindgren
2022-06-09  9:47       ` Peter Zijlstra
2022-06-09  9:47         ` Peter Zijlstra
2022-06-09  9:47         ` Peter Zijlstra
2022-06-09  9:47         ` Peter Zijlstra
2022-06-09  9:47         ` Peter Zijlstra
2022-06-09  9:47         ` Peter Zijlstra
2022-06-09  9:47         ` Peter Zijlstra
2022-06-09  9:47         ` Peter Zijlstra
2022-06-09  9:40     ` Peter Zijlstra
2022-06-09  9:40       ` Peter Zijlstra
2022-06-09  9:40       ` Peter Zijlstra
2022-06-09  9:40       ` Peter Zijlstra
2022-06-09  9:40       ` Peter Zijlstra
2022-06-09  9:40       ` Peter Zijlstra
2022-06-09  9:40       ` Peter Zijlstra
2022-06-09  9:40       ` Peter Zijlstra
2022-06-13 12:36   ` Tony Lindgren
2022-06-13 12:36     ` Tony Lindgren
2022-06-13 12:36     ` Tony Lindgren
2022-06-13 12:36     ` Tony Lindgren
2022-06-13 12:36     ` Tony Lindgren
2022-06-13 12:36     ` Tony Lindgren
2022-06-13 12:36     ` Tony Lindgren
2022-06-08 14:27 ` [PATCH 34/36] cpuidle,omap3: Push RCU-idle into omap_sram_idle() Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 15:04   ` Peter Zijlstra
2022-06-08 15:04     ` Peter Zijlstra
2022-06-08 15:04     ` Peter Zijlstra
2022-06-08 15:04     ` Peter Zijlstra
2022-06-08 15:04     ` Peter Zijlstra
2022-06-13 12:35     ` Tony Lindgren
2022-06-13 12:35       ` Tony Lindgren
2022-06-13 12:35       ` Tony Lindgren
2022-06-13 12:35       ` Tony Lindgren
2022-06-13 12:35       ` Tony Lindgren
2022-06-13 12:35       ` Tony Lindgren
2022-06-13 12:35       ` Tony Lindgren
2022-06-08 15:04   ` Peter Zijlstra
2022-06-08 15:04   ` Peter Zijlstra
2022-06-13 12:39   ` [PATCH 34.5/36] cpuidle,omap4: Push RCU-idle into omap4_enter_lowpower() Tony Lindgren
2022-06-13 12:39     ` Tony Lindgren
2022-06-13 12:39     ` Tony Lindgren
2022-06-13 12:39     ` Tony Lindgren
2022-06-13 12:39     ` Tony Lindgren
2022-06-13 12:39     ` Tony Lindgren
2022-06-13 12:39     ` Tony Lindgren
2022-06-14 22:12     ` Peter Zijlstra
2022-06-14 22:12       ` Peter Zijlstra
2022-06-14 22:12       ` Peter Zijlstra
2022-06-14 22:12       ` Peter Zijlstra
2022-06-14 22:12       ` Peter Zijlstra
2022-06-14 22:12       ` Peter Zijlstra
2022-06-14 22:12       ` Peter Zijlstra
2022-06-14 22:12       ` Peter Zijlstra
2022-06-15  5:35       ` Tony Lindgren
2022-06-15  5:35         ` Tony Lindgren
2022-06-15  5:35         ` Tony Lindgren
2022-06-15  5:35         ` Tony Lindgren
2022-06-15  5:35         ` Tony Lindgren
2022-06-15  5:35         ` Tony Lindgren
2022-06-15  5:35         ` Tony Lindgren
2023-01-13 12:31     ` [tip: sched/core] cpuidle, OMAP4: " tip-bot2 for Tony Lindgren
2022-06-08 14:27 ` [PATCH 35/36] cpuidle,powerdomain: Remove trace_.*_rcuidle() Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27 ` [PATCH 36/36] cpuidle,clk: " Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 14:27   ` Peter Zijlstra
2022-06-08 20:03   ` Stephen Boyd
2022-06-08 20:03     ` Stephen Boyd
2022-06-08 20:03     ` Stephen Boyd
2022-06-08 20:03     ` Stephen Boyd
2022-06-14 11:19 ` [PATCH 00/36] cpuidle,rcu: Cleanup the mess Mark Rutland
2022-06-14 11:19   ` Mark Rutland
2022-06-14 11:19   ` Mark Rutland
2022-06-14 11:19   ` Mark Rutland
2022-06-14 11:19   ` Mark Rutland
2022-06-14 11:19   ` Mark Rutland
2022-06-14 11:19   ` Mark Rutland
2022-06-14 11:19   ` Mark Rutland
2022-06-14 16:58   ` Peter Zijlstra
2022-06-14 16:58     ` Peter Zijlstra
2022-06-14 16:58     ` Peter Zijlstra
2022-06-14 16:58     ` Peter Zijlstra
2022-06-14 16:58     ` Peter Zijlstra
2022-06-14 16:58     ` Peter Zijlstra
2022-06-14 16:58     ` Peter Zijlstra
2022-06-14 16:58     ` Peter Zijlstra
2022-06-14 17:33     ` Mark Rutland
2022-06-14 17:33       ` Mark Rutland
2022-06-14 17:33       ` Mark Rutland
2022-06-14 17:33       ` Mark Rutland
2022-06-14 17:33       ` Mark Rutland
2022-06-14 17:33       ` Mark Rutland
2022-06-14 17:33       ` Mark Rutland
2022-06-14 17:33       ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220730094800.GB1587@lespinasse.org \
    --to=michel@lespinasse.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=acme@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=agross@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=amakhalov@vmware.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=bcain@quicinc.com \
    --cc=benh@kernel.crashing.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=chris@zankel.net \
    --cc=dalias@libc.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=dietmar.eggemann@arm.com \
    --cc=dinguyen@kernel.org \
    --cc=festevam@gmail.com \
    --cc=frederic@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guoren@kernel.org \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jgross@suse.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=johannes@sipsolutions.net \
    --cc=john.ogness@linutronix.de \
    --cc=jolsa@kernel.org \
    --cc=jonas@southpole.se \
    --cc=jonathanh@nvidia.com \
    --cc=josh@joshtriplett.org \
    --cc=jpoimboe@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=kernel@pengutronix.de \
    --cc=kernel@xen0n.name \
    --cc=khilman@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mattst88@gmail.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=monstr@monstr.eu \
    --cc=mpe@ellerman.id.au \
    --cc=mturquette@baylibre.com \
    --cc=namhyung@kernel.org \
    --cc=openrisc@lists.librecores.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paulmck@kernel.org \
    --cc=paulus@samba.org \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=pv-drivers@vmware.com \
    --cc=quic_neeraju@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rh0@fb.com \
    --cc=richard@nod.at \
    --cc=rostedt@goodmis.org \
    --cc=rth@twiddle.net \
    --cc=s.hauer@pengutronix.de \
    --cc=sammy@sammy.net \
    --cc=sboyd@kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=shawnguo@kernel.org \
    --cc=shorne@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=srivatsa@csail.mit.edu \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=sudeep.holla@arm.com \
    --cc=svens@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    --cc=tony@atomide.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=ulli.kroll@googlemail.com \
    --cc=vgupta@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=vschneid@redhat.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=ysato@users.sourceforge.jp \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.