All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Anders Roxell <anders.roxell@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>, Jann Horn <jannh@google.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	rcu@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] kfence: Avoid stalling work queue task without allocations
Date: Thu, 12 Nov 2020 19:12:54 +0100	[thread overview]
Message-ID: <20201112181254.GA3113918@elver.google.com> (raw)
In-Reply-To: <20201112175406.GF3249@paulmck-ThinkPad-P72>

[-- Attachment #1: Type: text/plain, Size: 21480 bytes --]

On Thu, Nov 12, 2020 at 09:54AM -0800, Paul E. McKenney wrote:
> On Thu, Nov 12, 2020 at 05:14:39PM +0100, Marco Elver wrote:
> > On Thu, Nov 12, 2020 at 01:49PM +0100, Marco Elver wrote:
> > > On Thu, 12 Nov 2020 at 01:11, Paul E. McKenney <paulmck@kernel.org> wrote:
> > [...]
> > > > > This assert didn't fire yet, I just get more of the below. I'll keep
> > > > > rerunning, but am not too hopeful...
> > > >
> > > > Is bisection a possibility?
> > > 
> > > I've been running a bisection for past ~12h, and am making slow
> > > progress. It might be another 12h, but I think it'll get there.
> > 
> > Bisection gave me this:
> > 
> > | git bisect start
> > | # bad: [c07b306d7fa5680777e2132662d2e6c19fb53579] kfence: Avoid stalling work queue task without allocations
> > | git bisect bad c07b306d7fa5680777e2132662d2e6c19fb53579
> > | # good: [3cea11cd5e3b00d91caf0b4730194039b45c5891] Linux 5.10-rc2
> > | git bisect good 27598e7e73260ed0b2917eb02d4a515ebb578313
> > | # good: [3e5acbea719e66ef3be64fe74c99cc905ca697dc] Merge remote-tracking branch 'wireless-drivers-next/master' into master
> > | git bisect good 3e5acbea719e66ef3be64fe74c99cc905ca697dc
> > | # good: [491a5a9a2fea28353d99621b8abb83b6928b4e36] Merge remote-tracking branch 'sound-asoc/for-next' into master
> > | git bisect good 491a5a9a2fea28353d99621b8abb83b6928b4e36
> > | # bad: [502f8643d6e21c7e370a0b75131130cc51609055] Merge remote-tracking branch 'phy-next/next' into master
> > | git bisect bad 502f8643d6e21c7e370a0b75131130cc51609055
> > | # good: [6693cb1fa5ea7b91ec00f9404776a095713face5] Merge remote-tracking branch 'tip/auto-latest' into master
> > | git bisect good 6693cb1fa5ea7b91ec00f9404776a095713face5
> > | # bad: [b790e3afead9357195b6d1e1b6cd9b3521503ad2] Merge branch 'tglx-pc.2020.10.30a' into HEAD
> > | git bisect bad b790e3afead9357195b6d1e1b6cd9b3521503ad2
> > | # bad: [765b512bb3d639bfad7dd43c288ee085236c7267] Merge branches 'cpuinfo.2020.11.06a', 'doc.2020.11.06a', 'fixes.2020.11.02a', 'lockdep.2020.11.02a', 'tasks.2020.11.06a' and 'torture.2020.11.06a' into HEAD
> > | git bisect bad 765b512bb3d639bfad7dd43c288ee085236c7267
> > | # good: [01f9e708d9eae6335ae9ff25ab09893c20727a55] tools/rcutorture: Fix BUG parsing of console.log
> 
> So torture.2020.11.06a is OK.
> 
> > | git bisect good 01f9e708d9eae6335ae9ff25ab09893c20727a55
> > | # good: [1be6ab91e2db157faedb7f16ab0636a80745a073] srcu: Take early exit on memory-allocation failure
> 
> As is fixes.2020.11.02a.
> 
> > | git bisect good 1be6ab91e2db157faedb7f16ab0636a80745a073
> > | # good: [65e9eb1ccfe56b41a0d8bfec651ea014968413cb] rcu: Prevent RCU_LOCKDEP_WARN() from swallowing the condition
> 
> And lockdep.2020.11.02a.
> 
> > | git bisect good 65e9eb1ccfe56b41a0d8bfec651ea014968413cb
> > | # good: [c386e29d43728778ddd642fa73cc582bee684171] docs/rcu: Update the call_rcu() API
> 
> And doc.2020.11.06a.
> 
> > | git bisect good c386e29d43728778ddd642fa73cc582bee684171
> > | # good: [27c0f1448389baf7f309b69e62d4b531c9395e88] rcutorture: Make grace-period kthread report match RCU flavor being tested
> 
> And the first three commits of tasks.2020.11.06a.
> 
> > | git bisect good 27c0f1448389baf7f309b69e62d4b531c9395e88
> > | # good: [3fcd6a230fa7d03bffcb831a81b40435c146c12b] x86/cpu: Avoid cpuinfo-induced IPIing of idle CPUs
> 
> And cpuinfo.2020.11.06a.
> 
> > | git bisect good 3fcd6a230fa7d03bffcb831a81b40435c146c12b
> > | # good: [75dc2da5ecd65bdcbfc4d59b9d9b7342c61fe374] rcu-tasks: Make the units of ->init_fract be jiffies
> 
> And the remaining commit of tasks.2020.11.06a.
> 
> > | git bisect good 75dc2da5ecd65bdcbfc4d59b9d9b7342c61fe374
> > | # first bad commit: [765b512bb3d639bfad7dd43c288ee085236c7267] Merge branches 'cpuinfo.2020.11.06a', 'doc.2020.11.06a', 'fixes.2020.11.02a', 'lockdep.2020.11.02a', 'tasks.2020.11.06a' and 'torture.2020.11.06a' into HEAD
> > 
> > This doesn't look very satisfying, given it's the merge commit. :-/
> 
> So each individual branch is just fine, but the merge of them is not.  Fun.
> 
> These have been passing quite a bit of rcutorture over here, including
> preemptible kernels running !SMP, but admittedly on x86 rather than ARMv8.

Note that this is ARMv8 on QEMU on an x86 host i.e. emulated. And it's
really slow as a result. Together with a bunch of debug tools including
lockdep.

> One approach would be to binary-search the combinations of merges.
> Except that there are six of them, so there are 64 combinations, of
> which you have tested only 8 thus far (none, one each, and all).
> 
> But are you sure that the bisection points labeled "good" really are good?
> For example, what is the distribution of first failure times in the
> points labeled "bad" vs. the runtime used to make a "good" determination?
> Alternatively, just try a longer run on each of the commits feeding into
> the merge point.

Yeah, I'm having doubts, and this might be even more non-deterministic
that I thought and some 'good' could maybe be 'bad' if I had re-run
them? I don't know. One thing I can try is to make sure I run it more
than once, but I'm definitely not doing that manually, so let me try and
script something so I don't have to hand-hold the bisection overnight.
:-)

> > > > Failing that, please see the updated patch below.  This adds a few more
> > > > calls to lockdep_assert_irqs_disabled(), but perhaps more helpfully dumps
> > > > the current stack of the CPU that the RCU grace-period kthread wants to
> > > > run on in the case where this kthread has been starved of CPU.
> > > 
> > > Thanks, I will apply that after the bisection runs.
> > 
> > Here's a new log with it applied:
> 
> Even more strangeness!  ;-)
> 
> > | [  118.480959] Key type dns_resolver registered
> > | [  118.487752] registered taskstats version 1
> > | [  118.489798] Running tests on all trace events:
> > | [  118.490164] Testing all events: OK
> > | [  173.304186] Running tests again, along with the function tracer
> > | [  173.320155] Running tests on all trace events:
> > | [  173.331638] Testing all events: 
> > | [  173.485044] hrtimer: interrupt took 14340976 ns
> 
> Fourteen milliseconds, so annoying from a real-time perspective, but
> unlikely to be the cause of this.
> 
> Was the system responsive at this point, between three and ten minutes
> after boot?  Similar question for the other gaps in the dmesg log.
> The reason for the question is that workqueue's reported stall times
> don't span these intervals.

The system is so slow at this point that I can't get much out of it
either way, other than waiting and seeing if it proceeds...

> > | [  334.160218] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 15s!
> 
> It might be instructive to cause this code to provoke a backtrace.
> I suggest adding something like "trigger_single_cpu_backtrace(cpu)"
> in kernel/workqueue.c's function named wq_watchdog_timer_fn()
> somewhere within its "if" statement that is preceded with the "did we
> stall?" comment.  Or just search for "BUG: workqueue lockup - pool"
> within kernel/workqueue.c.
> 
> > | [  334.259490] Showing busy workqueues and worker pools:
> > | [  334.265398] workqueue events: flags=0x0
> > | [  334.289070]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
> > | [  334.300659]     pending: vmstat_shepherd
> > | [  453.541827] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 10s!
> > | [  453.655731] BUG: workqueue lockup - pool cpus=0 flags=0x4 nice=0 stuck for 10s!
> > | [  453.759839] Showing busy workqueues and worker pools:
> > | [  453.784294] workqueue events: flags=0x0
> > | [  453.812207]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
> > | [  453.822108]     pending: vmstat_shepherd
> > | [  453.839855] workqueue events_power_efficient: flags=0x82
> > | [  453.865152]   pwq 2: cpus=0 flags=0x4 nice=0 active=2/256 refcnt=4
> > | [  453.874553]     pending: neigh_periodic_work, do_cache_clean
> > | [  481.424362] BUG: workqueue lockup - pool cpus=0 flags=0x4 nice=0 stuck for 10s!
> > | [  481.508136] Showing busy workqueues and worker pools:
> > | [  481.524265] workqueue events: flags=0x0
> > | [  481.550480]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
> > | [  481.560690]     pending: vmstat_shepherd
> > | [  481.571255] workqueue events_power_efficient: flags=0x82
> > | [  481.592515]   pwq 2: cpus=0 flags=0x4 nice=0 active=1/256 refcnt=3
> > | [  481.601153]     pending: neigh_periodic_work
> > | [  532.108407] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 10s!
> > | [  532.203476] Showing busy workqueues and worker pools:
> > | [  532.215930] workqueue events: flags=0x0
> > | [  532.244203]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
> > | [  532.254428]     pending: vmstat_shepherd
> > | [  739.567892] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 19s!
> > | [  739.656419] Showing busy workqueues and worker pools:
> > | [  739.699514] workqueue events: flags=0x0
> > | [  739.705111]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
> > | [  739.715393]     pending: vmstat_shepherd
> > | [  739.733403] workqueue events_power_efficient: flags=0x82
> > | [  739.739433]   pwq 2: cpus=0 flags=0x4 nice=0 active=2/256 refcnt=4
> > | [  739.748156]     pending: check_lifetime, neigh_periodic_work
> > | [  811.578165] BUG: workqueue lockup - pool cpus=0 flags=0x5 nice=0 stuck for 14s!
> > | [  811.602913] Showing busy workqueues and worker pools:
> > | [  811.620424] workqueue events: flags=0x0
> > | [  811.652479]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
> > | [  811.662686]     pending: vmstat_shepherd
> > | [  811.683811] workqueue events_power_efficient: flags=0x82
> > | [  811.716123]   pwq 2: cpus=0 flags=0x5 nice=0 active=1/256 refcnt=3
> > | [  811.724857]     pending: neigh_periodic_work
> > | [  811.749989] pool 2: cpus=0 flags=0x5 nice=0 hung=14s workers=2 manager: 61 idle: 7
> > | [  822.456290] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 11s!
> > | [  822.600359] BUG: workqueue lockup - pool cpus=0 flags=0x5 nice=0 stuck for 25s!
> > | [  822.675814] Showing busy workqueues and worker pools:
> > | [  822.720098] workqueue events: flags=0x0
> > | [  822.747304]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
> > | [  822.757174]     pending: vmstat_shepherd
> > | [  822.768047] workqueue events_power_efficient: flags=0x82
> > | [  822.799954]   pwq 2: cpus=0 flags=0x5 nice=0 active=1/256 refcnt=3
> > | [  822.808488]     pending: neigh_periodic_work
> > | [  822.831900] pool 2: cpus=0 flags=0x5 nice=0 hung=25s workers=2 manager: 61 idle: 7
> > | [  834.116239] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 22s!
> > | [  834.246557] BUG: workqueue lockup - pool cpus=0 flags=0x5 nice=0 stuck for 37s!
> > | [  834.271069] Showing busy workqueues and worker pools:
> > | [  834.276687] workqueue events: flags=0x0
> > | [  834.296267]   pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
> > | [  834.306148]     pending: vmstat_shepherd
> > | [  834.324273] workqueue events_power_efficient: flags=0x82
> > | [  834.344433]   pwq 2: cpus=0 flags=0x5 nice=0 active=2/256 refcnt=4
> > | [  834.352891]     pending: neigh_periodic_work, do_cache_clean
> > | [  834.384530] pool 2: cpus=0 flags=0x5 nice=0 hung=37s workers=2 manager: 61 idle: 7
> > | [  840.906940] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> > | [  840.912685] 	(detected by 0, t=3752 jiffies, g=2709, q=1)
> 
> CPU 0 detected the stall.
> 
> > | [  840.914587] rcu: All QSes seen, last rcu_preempt kthread activity 620 (4295099794-4295099174), jiffies_till_next_fqs=1, root ->qsmask 0x0
> 
> As before, the grace period is not stalled, but instead the grace-period
> kthread is failing to detect the end of an already-ended grace period.
> 
> > | [  840.925016] rcu: rcu_preempt kthread starved for 620 jiffies! g2709 f0x2 RCU_GP_CLEANUP(7) ->state=0x0 ->cpu=0
> 
> And CPU 0 is where the RCU grace-period kthread was last seen running.
> 
> > | [  840.930687] rcu: 	Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
> > | [  840.936056] rcu: RCU grace-period kthread stack dump:
> > | [  840.940433] task:rcu_preempt     state:R  running task     stack:    0 pid:   10 ppid:     2 flags:0x00000428
> > | [  840.949160] Call trace:
> > | [  840.952822]  dump_backtrace+0x0/0x278
> > | [  840.956816]  show_stack+0x30/0x80
> > | [  840.960643]  sched_show_task+0x1a8/0x240
> > | [  840.964684]  rcu_check_gp_kthread_starvation+0x170/0x358
> > | [  840.969113]  rcu_sched_clock_irq+0x744/0xd18
> > | [  840.973232]  update_process_times+0x68/0x98
> > | [  840.977308]  tick_sched_handle.isra.16+0x54/0x80
> > | [  840.981504]  tick_sched_timer+0x64/0xd8
> > | [  840.985500]  __hrtimer_run_queues+0x2a4/0x750
> > | [  840.989628]  hrtimer_interrupt+0xf4/0x2a0
> > | [  840.993669]  arch_timer_handler_virt+0x44/0x70
> > | [  840.997841]  handle_percpu_devid_irq+0xfc/0x4d0
> > | [  841.002043]  generic_handle_irq+0x50/0x70
> > | [  841.006098]  __handle_domain_irq+0x9c/0x120
> > | [  841.010188]  gic_handle_irq+0xcc/0x108
> > | [  841.014132]  el1_irq+0xbc/0x180
> > | [  841.017935]  arch_local_irq_restore+0x4/0x8
> > | [  841.021993]  trace_preempt_on+0xf4/0x190
> > | [  841.026016]  preempt_schedule_common+0x12c/0x1b0
> > | [  841.030193]  preempt_schedule.part.88+0x20/0x28
> > | [  841.034373]  preempt_schedule+0x20/0x28
> > | [  841.038369]  _raw_spin_unlock_irq+0x80/0x90
> > | [  841.042498]  rcu_gp_kthread+0xe5c/0x19a8
> > | [  841.046504]  kthread+0x174/0x188
> > | [  841.050320]  ret_from_fork+0x10/0x18
> > | [  841.054312] rcu: Stack dump where RCU grace-period kthread last ran:
> > | [  841.058980] Task dump for CPU 0:
> > | [  841.062736] task:rcu_preempt     state:R  running task     stack:    0 pid:   10 ppid:     2 flags:0x00000428
> 
> And RCU's grace-period kthread really is running on CPU 0 right now.
> It is just not making any forward progress.
> 
> > | [  841.071073] Call trace:
> > | [  841.074662]  dump_backtrace+0x0/0x278
> > | [  841.078596]  show_stack+0x30/0x80
> > | [  841.082386]  sched_show_task+0x1a8/0x240
> > | [  841.086367]  dump_cpu_task+0x48/0x58
> > | [  841.090311]  rcu_check_gp_kthread_starvation+0x214/0x358
> > | [  841.094736]  rcu_sched_clock_irq+0x744/0xd18
> > | [  841.098852]  update_process_times+0x68/0x98
> > | [  841.102949]  tick_sched_handle.isra.16+0x54/0x80
> > | [  841.107119]  tick_sched_timer+0x64/0xd8
> > | [  841.111127]  __hrtimer_run_queues+0x2a4/0x750
> > | [  841.115264]  hrtimer_interrupt+0xf4/0x2a0
> > | [  841.119319]  arch_timer_handler_virt+0x44/0x70
> > | [  841.123525]  handle_percpu_devid_irq+0xfc/0x4d0
> > | [  841.127690]  generic_handle_irq+0x50/0x70
> > | [  841.131702]  __handle_domain_irq+0x9c/0x120
> > | [  841.135779]  gic_handle_irq+0xcc/0x108
> > | [  841.139743]  el1_irq+0xbc/0x180
> 
> The code above this point was detecting and printing the RCU CPU stall
> warning.  The code below this point was doing what?
> 
> Any chance of getting file names and line numbers for the rest of this
> stack?

I've attached a version of the log with line numbers.

> > | [  841.143527]  arch_local_irq_restore+0x4/0x8
> 
> So we are just now restoring interrupts, hence our getting the
> interrupt at this point..
> 
> > | [  841.147612]  trace_preempt_on+0xf4/0x190
> 
> From within the trace code, which is apparently recording the fact
> that preemption is being enabled.
> 
> > | [  841.151656]  preempt_schedule_common+0x12c/0x1b0
> > | [  841.155869]  preempt_schedule.part.88+0x20/0x28
> > | [  841.160036]  preempt_schedule+0x20/0x28
> 
> I was not aware that releasing a raw spinlock could result in a direct
> call to preempt_schedule().
> 
> > | [  841.164051]  _raw_spin_unlock_irq+0x80/0x90
> > | [  841.168139]  rcu_gp_kthread+0xe5c/0x19a8
> 
> So the RCU grace-period kthread has spent many seconds attempting to
> release a lock?  Am I reading this correctly?  Mark Rutland, am I missing
> something here?
> 
> > | [  841.172134]  kthread+0x174/0x188
> > | [  841.175953]  ret_from_fork+0x10/0x18
> > | [  841.191371] 
> > | [  841.193648] ================================
> > | [  841.196605] WARNING: inconsistent lock state
> > | [  841.199764] 5.10.0-rc3-next-20201110-00001-gc07b306d7fa5-dirty #23 Not tainted
> > | [  841.203564] --------------------------------
> 
> Has lockdep recorded the fact that the lock is actually released?
> It had better, given that interrupts are now enabled.
> 
> > | [  841.206550] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> > | [  841.210074] rcu_preempt/10 [HC0[0]:SC0[0]:HE0:SE1] takes:
> > | [  841.213453] ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: rcu_sched_clock_irq+0x4a0/0xd18
> > | [  841.221240] {IN-HARDIRQ-W} state was registered at:
> > | [  841.224538]   __lock_acquire+0x7bc/0x15b8
> > | [  841.227541]   lock_acquire+0x244/0x498
> > | [  841.230442]   _raw_spin_lock_irqsave+0x78/0x144
> > | [  841.233555]   rcu_sched_clock_irq+0x4a0/0xd18
> > | [  841.236621]   update_process_times+0x68/0x98
> > | [  841.239645]   tick_sched_handle.isra.16+0x54/0x80
> > | [  841.242801]   tick_sched_timer+0x64/0xd8
> > | [  841.245745]   __hrtimer_run_queues+0x2a4/0x750
> > | [  841.248842]   hrtimer_interrupt+0xf4/0x2a0
> > | [  841.251846]   arch_timer_handler_virt+0x44/0x70
> > | [  841.254976]   handle_percpu_devid_irq+0xfc/0x4d0
> > | [  841.258131]   generic_handle_irq+0x50/0x70
> > | [  841.261146]   __handle_domain_irq+0x9c/0x120
> > | [  841.264169]   gic_handle_irq+0xcc/0x108
> > | [  841.267096]   el1_irq+0xbc/0x180
> > | [  841.269844]   arch_local_irq_restore+0x4/0x8
> > | [  841.272881]   trace_preempt_on+0xf4/0x190
> > | [  841.275847]   preempt_schedule_common+0x12c/0x1b0
> > | [  841.279017]   preempt_schedule.part.88+0x20/0x28
> > | [  841.282149]   preempt_schedule+0x20/0x28
> > | [  841.285112]   _raw_spin_unlock_irq+0x80/0x90
> > | [  841.288154]   rcu_gp_kthread+0xe5c/0x19a8
> > | [  841.291175]   kthread+0x174/0x188
> > | [  841.293952]   ret_from_fork+0x10/0x18
> > | [  841.296780] irq event stamp: 39750
> > | [  841.299604] hardirqs last  enabled at (39749): [<ffffd787e6d85738>] rcu_irq_enter_irqson+0x48/0x68
> > | [  841.303961] hardirqs last disabled at (39750): [<ffffd787e6c122bc>] el1_irq+0x7c/0x180
> > | [  841.308042] softirqs last  enabled at (36704): [<ffffd787e6c10b58>] __do_softirq+0x650/0x6a4
> > | [  841.312250] softirqs last disabled at (36683): [<ffffd787e6cc0b80>] irq_exit+0x1a8/0x1b0
> > | [  841.316257] 
> > | [  841.316257] other info that might help us debug this:
> > | [  841.319834]  Possible unsafe locking scenario:
> > | [  841.319834] 
> > | [  841.323217]        CPU0
> > | [  841.325656]        ----
> > | [  841.328097]   lock(rcu_node_0);
> > | [  841.332433]   <Interrupt>
> > | [  841.334966]     lock(rcu_node_0);
> > | [  841.339379] 
> > | [  841.339379]  *** DEADLOCK ***
> > | [  841.339379] 
> > | [  841.342829] 1 lock held by rcu_preempt/10:
> > | [  841.345794]  #0: ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: rcu_sched_clock_irq+0x4a0/0xd18
> > | [  841.354415] 
> > | [  841.354415] stack backtrace:
> > | [  841.357664] CPU: 0 PID: 10 Comm: rcu_preempt Not tainted 5.10.0-rc3-next-20201110-00001-gc07b306d7fa5-dirty #23
> > | [  841.362249] Hardware name: linux,dummy-virt (DT)
> > | [  841.365352] Call trace:
> > | [  841.367862]  dump_backtrace+0x0/0x278
> > | [  841.370745]  show_stack+0x30/0x80
> > | [  841.373517]  dump_stack+0x138/0x1b0
> > | [  841.376339]  print_usage_bug+0x2d8/0x2f8
> > | [  841.379288]  mark_lock.part.46+0x370/0x480
> > | [  841.382304]  mark_held_locks+0x58/0x90
> > | [  841.385228]  lockdep_hardirqs_on_prepare+0xdc/0x298
> > | [  841.388452]  trace_hardirqs_on+0x90/0x388
> > | [  841.391434]  el1_irq+0xd8/0x180
> > | [  841.394178]  arch_local_irq_restore+0x4/0x8
> > | [  841.397186]  trace_preempt_on+0xf4/0x190
> > | [  841.400127]  preempt_schedule_common+0x12c/0x1b0
> > | [  841.403246]  preempt_schedule.part.88+0x20/0x28
> > | [  841.406347]  preempt_schedule+0x20/0x28
> > | [  841.409278]  _raw_spin_unlock_irq+0x80/0x90
> > | [  841.412290]  rcu_gp_kthread+0xe5c/0x19a8
> > | [  841.415237]  kthread+0x174/0x188
> > | [  841.418011]  ret_from_fork+0x10/0x18
> > | [  841.423450] BUG: scheduling while atomic: rcu_preempt/10/0x00000002
> > | [  841.431367] INFO: lockdep is turned off.
> > | [  841.439132] Modules linked in:
> > | [  841.450608] Preemption disabled at:
> > | [  841.452261] [<ffffd787e7fffec0>] preempt_schedule.part.88+0x20/0x28
> > | [  841.467324] CPU: 0 PID: 10 Comm: rcu_preempt Not tainted 5.10.0-rc3-next-20201110-00001-gc07b306d7fa5-dirty #23
> > | [  841.471926] Hardware name: linux,dummy-virt (DT)
> > | [  841.475030] Call trace:
> > | [  841.477581]  dump_backtrace+0x0/0x278
> > | [  841.480451]  show_stack+0x30/0x80
> > | [  841.483220]  dump_stack+0x138/0x1b0
> > | [  841.486057]  __schedule_bug+0x8c/0xe8
> > | [  841.488949]  __schedule+0x7e8/0x890
> > | [  841.491801]  preempt_schedule_common+0x44/0x1b0
> > | [  841.494927]  preempt_schedule.part.88+0x20/0x28
> > | [  841.498048]  preempt_schedule+0x20/0x28
> > | [  841.500963]  _raw_spin_unlock_irq+0x80/0x90
> > | [  841.503988]  rcu_gp_kthread+0xe5c/0x19a8
> > | [  841.506965]  kthread+0x174/0x188
> > | [  841.509732]  ret_from_fork+0x10/0x18

[-- Attachment #2: bug.log --]
[-- Type: text/plain, Size: 15640 bytes --]

Testing all events: OK
Running tests again, along with the function tracer
Running tests on all trace events:
Testing all events: 
hrtimer: interrupt took 14340976 ns
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 15s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
  pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
    pending: vmstat_shepherd
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 10s!
BUG: workqueue lockup - pool cpus=0 flags=0x4 nice=0 stuck for 10s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
  pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
    pending: vmstat_shepherd
workqueue events_power_efficient: flags=0x82
  pwq 2: cpus=0 flags=0x4 nice=0 active=2/256 refcnt=4
    pending: neigh_periodic_work, do_cache_clean
BUG: workqueue lockup - pool cpus=0 flags=0x4 nice=0 stuck for 10s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
  pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
    pending: vmstat_shepherd
workqueue events_power_efficient: flags=0x82
  pwq 2: cpus=0 flags=0x4 nice=0 active=1/256 refcnt=3
    pending: neigh_periodic_work
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 10s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
  pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
    pending: vmstat_shepherd
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 19s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
  pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
    pending: vmstat_shepherd
workqueue events_power_efficient: flags=0x82
  pwq 2: cpus=0 flags=0x4 nice=0 active=2/256 refcnt=4
    pending: check_lifetime, neigh_periodic_work
BUG: workqueue lockup - pool cpus=0 flags=0x5 nice=0 stuck for 14s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
  pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
    pending: vmstat_shepherd
workqueue events_power_efficient: flags=0x82
  pwq 2: cpus=0 flags=0x5 nice=0 active=1/256 refcnt=3
    pending: neigh_periodic_work
pool 2: cpus=0 flags=0x5 nice=0 hung=14s workers=2 manager: 61 idle: 7
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 11s!
BUG: workqueue lockup - pool cpus=0 flags=0x5 nice=0 stuck for 25s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
  pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
    pending: vmstat_shepherd
workqueue events_power_efficient: flags=0x82
  pwq 2: cpus=0 flags=0x5 nice=0 active=1/256 refcnt=3
    pending: neigh_periodic_work
pool 2: cpus=0 flags=0x5 nice=0 hung=25s workers=2 manager: 61 idle: 7
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 22s!
BUG: workqueue lockup - pool cpus=0 flags=0x5 nice=0 stuck for 37s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
  pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2
    pending: vmstat_shepherd
workqueue events_power_efficient: flags=0x82
  pwq 2: cpus=0 flags=0x5 nice=0 active=2/256 refcnt=4
    pending: neigh_periodic_work, do_cache_clean
pool 2: cpus=0 flags=0x5 nice=0 hung=37s workers=2 manager: 61 idle: 7
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
	(detected by 0, t=3752 jiffies, g=2709, q=1)
rcu: All QSes seen, last rcu_preempt kthread activity 620 (4295099794-4295099174), jiffies_till_next_fqs=1, root ->qsmask 0x0
rcu: rcu_preempt kthread starved for 620 jiffies! g2709 f0x2 RCU_GP_CLEANUP(7) ->state=0x0 ->cpu=0
rcu: 	Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt     state:R  running task     stack:    0 pid:   10 ppid:     2 flags:0x00000428
Call trace:
 dump_backtrace+0x0/0x278 arch/arm64/kernel/stacktrace.c:100
 show_stack+0x30/0x80 arch/arm64/kernel/stacktrace.c:196
 sched_show_task+0x1a8/0x240 kernel/sched/core.c:6445
 rcu_check_gp_kthread_starvation+0x170/0x358 kernel/rcu/tree_stall.h:469
 print_other_cpu_stall kernel/rcu/tree_stall.h:544 [inline]
 check_cpu_stall kernel/rcu/tree_stall.h:664 [inline]
 rcu_pending kernel/rcu/tree.c:3752 [inline]
 rcu_sched_clock_irq+0x744/0xd18 kernel/rcu/tree.c:2581
 update_process_times+0x68/0x98 kernel/time/timer.c:1709
 tick_sched_handle.isra.16+0x54/0x80 kernel/time/tick-sched.c:176
 tick_sched_timer+0x64/0xd8 kernel/time/tick-sched.c:1328
 __run_hrtimer kernel/time/hrtimer.c:1519 [inline]
 __hrtimer_run_queues+0x2a4/0x750 kernel/time/hrtimer.c:1583
 hrtimer_interrupt+0xf4/0x2a0 kernel/time/hrtimer.c:1645
 timer_handler drivers/clocksource/arm_arch_timer.c:647 [inline]
 arch_timer_handler_virt+0x44/0x70 drivers/clocksource/arm_arch_timer.c:658
 handle_percpu_devid_irq+0xfc/0x4d0 kernel/irq/chip.c:930
 generic_handle_irq_desc include/linux/irqdesc.h:152 [inline]
 generic_handle_irq+0x50/0x70 kernel/irq/irqdesc.c:650
 __handle_domain_irq+0x9c/0x120 kernel/irq/irqdesc.c:687
 handle_domain_irq include/linux/irqdesc.h:170 [inline]
 gic_handle_irq+0xcc/0x108 drivers/irqchip/irq-gic.c:370
 el1_irq+0xbc/0x180 arch/arm64/kernel/entry.S:651
 arch_local_irq_restore+0x4/0x8 arch/arm64/include/asm/irqflags.h:124
 trace_preempt_enable_rcuidle include/trace/events/preemptirq.h:55 [inline]
 trace_preempt_on+0xf4/0x190 kernel/trace/trace_preemptirq.c:123
 preempt_latency_stop kernel/sched/core.c:4197 [inline]
 preempt_schedule_common+0x12c/0x1b0 kernel/sched/core.c:4682
 preempt_schedule.part.88+0x20/0x28 kernel/sched/core.c:4706
 preempt_schedule+0x20/0x28 kernel/sched/core.c:4707
 __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline]
 _raw_spin_unlock_irq+0x80/0x90 kernel/locking/spinlock.c:199
 rcu_gp_cleanup kernel/rcu/tree.c:2046 [inline]
 rcu_gp_kthread+0xe5c/0x19a8 kernel/rcu/tree.c:2119
 kthread+0x174/0x188 kernel/kthread.c:292
 ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:961
rcu: Stack dump where RCU grace-period kthread last ran:
Task dump for CPU 0:
task:rcu_preempt     state:R  running task     stack:    0 pid:   10 ppid:     2 flags:0x00000428
Call trace:
 dump_backtrace+0x0/0x278 arch/arm64/kernel/stacktrace.c:100
 show_stack+0x30/0x80 arch/arm64/kernel/stacktrace.c:196
 sched_show_task+0x1a8/0x240 kernel/sched/core.c:6445
 dump_cpu_task+0x48/0x58 kernel/sched/core.c:8428
 rcu_check_gp_kthread_starvation+0x214/0x358 kernel/rcu/tree_stall.h:474
 print_other_cpu_stall kernel/rcu/tree_stall.h:544 [inline]
 check_cpu_stall kernel/rcu/tree_stall.h:664 [inline]
 rcu_pending kernel/rcu/tree.c:3752 [inline]
 rcu_sched_clock_irq+0x744/0xd18 kernel/rcu/tree.c:2581
 update_process_times+0x68/0x98 kernel/time/timer.c:1709
 tick_sched_handle.isra.16+0x54/0x80 kernel/time/tick-sched.c:176
 tick_sched_timer+0x64/0xd8 kernel/time/tick-sched.c:1328
 __run_hrtimer kernel/time/hrtimer.c:1519 [inline]
 __hrtimer_run_queues+0x2a4/0x750 kernel/time/hrtimer.c:1583
 hrtimer_interrupt+0xf4/0x2a0 kernel/time/hrtimer.c:1645
 timer_handler drivers/clocksource/arm_arch_timer.c:647 [inline]
 arch_timer_handler_virt+0x44/0x70 drivers/clocksource/arm_arch_timer.c:658
 handle_percpu_devid_irq+0xfc/0x4d0 kernel/irq/chip.c:930
 generic_handle_irq_desc include/linux/irqdesc.h:152 [inline]
 generic_handle_irq+0x50/0x70 kernel/irq/irqdesc.c:650
 __handle_domain_irq+0x9c/0x120 kernel/irq/irqdesc.c:687
 handle_domain_irq include/linux/irqdesc.h:170 [inline]
 gic_handle_irq+0xcc/0x108 drivers/irqchip/irq-gic.c:370
 el1_irq+0xbc/0x180 arch/arm64/kernel/entry.S:651
 arch_local_irq_restore+0x4/0x8 arch/arm64/include/asm/irqflags.h:124
 trace_preempt_enable_rcuidle include/trace/events/preemptirq.h:55 [inline]
 trace_preempt_on+0xf4/0x190 kernel/trace/trace_preemptirq.c:123
 preempt_latency_stop kernel/sched/core.c:4197 [inline]
 preempt_schedule_common+0x12c/0x1b0 kernel/sched/core.c:4682
 preempt_schedule.part.88+0x20/0x28 kernel/sched/core.c:4706
 preempt_schedule+0x20/0x28 kernel/sched/core.c:4707
 __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline]
 _raw_spin_unlock_irq+0x80/0x90 kernel/locking/spinlock.c:199
 rcu_gp_cleanup kernel/rcu/tree.c:2046 [inline]
 rcu_gp_kthread+0xe5c/0x19a8 kernel/rcu/tree.c:2119
 kthread+0x174/0x188 kernel/kthread.c:292
 ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:961

================================
WARNING: inconsistent lock state
5.10.0-rc3-next-20201110-00001-gc07b306d7fa5-dirty #23 Not tainted
--------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
rcu_preempt/10 [HC0[0]:SC0[0]:HE0:SE1] takes:
ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: print_other_cpu_stall kernel/rcu/tree_stall.h:505 [inline]
ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: check_cpu_stall kernel/rcu/tree_stall.h:664 [inline]
ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: rcu_pending kernel/rcu/tree.c:3752 [inline]
ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: rcu_sched_clock_irq+0x4a0/0xd18 kernel/rcu/tree.c:2581
{IN-HARDIRQ-W} state was registered at:
  mark_lock kernel/locking/lockdep.c:4293 [inline]
  mark_usage kernel/locking/lockdep.c:4302 [inline]
  __lock_acquire+0x7bc/0x15b8 kernel/locking/lockdep.c:4785
  lock_acquire+0x244/0x498 kernel/locking/lockdep.c:5436
  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
  _raw_spin_lock_irqsave+0x78/0x144 kernel/locking/spinlock.c:159
  print_other_cpu_stall kernel/rcu/tree_stall.h:505 [inline]
  check_cpu_stall kernel/rcu/tree_stall.h:664 [inline]
  rcu_pending kernel/rcu/tree.c:3752 [inline]
  rcu_sched_clock_irq+0x4a0/0xd18 kernel/rcu/tree.c:2581
  update_process_times+0x68/0x98 kernel/time/timer.c:1709
  tick_sched_handle.isra.16+0x54/0x80 kernel/time/tick-sched.c:176
  tick_sched_timer+0x64/0xd8 kernel/time/tick-sched.c:1328
  __run_hrtimer kernel/time/hrtimer.c:1519 [inline]
  __hrtimer_run_queues+0x2a4/0x750 kernel/time/hrtimer.c:1583
  hrtimer_interrupt+0xf4/0x2a0 kernel/time/hrtimer.c:1645
  timer_handler drivers/clocksource/arm_arch_timer.c:647 [inline]
  arch_timer_handler_virt+0x44/0x70 drivers/clocksource/arm_arch_timer.c:658
  handle_percpu_devid_irq+0xfc/0x4d0 kernel/irq/chip.c:930
  generic_handle_irq_desc include/linux/irqdesc.h:152 [inline]
  generic_handle_irq+0x50/0x70 kernel/irq/irqdesc.c:650
  __handle_domain_irq+0x9c/0x120 kernel/irq/irqdesc.c:687
  handle_domain_irq include/linux/irqdesc.h:170 [inline]
  gic_handle_irq+0xcc/0x108 drivers/irqchip/irq-gic.c:370
  el1_irq+0xbc/0x180 arch/arm64/kernel/entry.S:651
  arch_local_irq_restore+0x4/0x8 arch/arm64/include/asm/irqflags.h:124
  trace_preempt_enable_rcuidle include/trace/events/preemptirq.h:55 [inline]
  trace_preempt_on+0xf4/0x190 kernel/trace/trace_preemptirq.c:123
  preempt_latency_stop kernel/sched/core.c:4197 [inline]
  preempt_schedule_common+0x12c/0x1b0 kernel/sched/core.c:4682
  preempt_schedule.part.88+0x20/0x28 kernel/sched/core.c:4706
  preempt_schedule+0x20/0x28 kernel/sched/core.c:4707
  __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline]
  _raw_spin_unlock_irq+0x80/0x90 kernel/locking/spinlock.c:199
  rcu_gp_cleanup kernel/rcu/tree.c:2046 [inline]
  rcu_gp_kthread+0xe5c/0x19a8 kernel/rcu/tree.c:2119
  kthread+0x174/0x188 kernel/kthread.c:292
  ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:961
irq event stamp: 39750
hardirqs last  enabled at (39749): [<ffffd787e6d85738>] rcu_irq_enter_irqson+0x48/0x68 kernel/rcu/tree.c:1078
hardirqs last disabled at (39750): [<ffffd787e6c122bc>] el1_irq+0x7c/0x180 arch/arm64/kernel/entry.S:648
softirqs last  enabled at (36704): [<ffffd787e6c10b58>] __do_softirq+0x650/0x6a4 kernel/softirq.c:325
softirqs last disabled at (36683): [<ffffd787e6cc0b80>] do_softirq_own_stack include/linux/interrupt.h:568 [inline]
softirqs last disabled at (36683): [<ffffd787e6cc0b80>] invoke_softirq kernel/softirq.c:393 [inline]
softirqs last disabled at (36683): [<ffffd787e6cc0b80>] __irq_exit_rcu kernel/softirq.c:423 [inline]
softirqs last disabled at (36683): [<ffffd787e6cc0b80>] irq_exit+0x1a8/0x1b0 kernel/softirq.c:447

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(rcu_node_0);
  <Interrupt>
    lock(rcu_node_0);

 *** DEADLOCK ***

1 lock held by rcu_preempt/10:
 #0: ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: print_other_cpu_stall kernel/rcu/tree_stall.h:505 [inline]
 #0: ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: check_cpu_stall kernel/rcu/tree_stall.h:664 [inline]
 #0: ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: rcu_pending kernel/rcu/tree.c:3752 [inline]
 #0: ffffd787e91d4358 (rcu_node_0){?.-.}-{2:2}, at: rcu_sched_clock_irq+0x4a0/0xd18 kernel/rcu/tree.c:2581

stack backtrace:
CPU: 0 PID: 10 Comm: rcu_preempt Not tainted 5.10.0-rc3-next-20201110-00001-gc07b306d7fa5-dirty #23
Hardware name: linux,dummy-virt (DT)
Call trace:
 dump_backtrace+0x0/0x278 arch/arm64/kernel/stacktrace.c:100
 show_stack+0x30/0x80 arch/arm64/kernel/stacktrace.c:196
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x138/0x1b0 lib/dump_stack.c:118
 print_usage_bug+0x2d8/0x2f8 kernel/locking/lockdep.c:3739
 valid_state kernel/locking/lockdep.c:3750 [inline]
 mark_lock_irq kernel/locking/lockdep.c:3953 [inline]
 mark_lock.part.46+0x370/0x480 kernel/locking/lockdep.c:4410
 mark_lock kernel/locking/lockdep.c:4008 [inline]
 mark_held_locks+0x58/0x90 kernel/locking/lockdep.c:4011
 __trace_hardirqs_on_caller kernel/locking/lockdep.c:4029 [inline]
 lockdep_hardirqs_on_prepare+0xdc/0x298 kernel/locking/lockdep.c:4097
 trace_hardirqs_on+0x90/0x388 kernel/trace/trace_preemptirq.c:49
 el1_irq+0xd8/0x180 arch/arm64/kernel/entry.S:685
 arch_local_irq_restore+0x4/0x8 arch/arm64/include/asm/irqflags.h:124
 trace_preempt_enable_rcuidle include/trace/events/preemptirq.h:55 [inline]
 trace_preempt_on+0xf4/0x190 kernel/trace/trace_preemptirq.c:123
 preempt_latency_stop kernel/sched/core.c:4197 [inline]
 preempt_schedule_common+0x12c/0x1b0 kernel/sched/core.c:4682
 preempt_schedule.part.88+0x20/0x28 kernel/sched/core.c:4706
 preempt_schedule+0x20/0x28 kernel/sched/core.c:4707
 __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline]
 _raw_spin_unlock_irq+0x80/0x90 kernel/locking/spinlock.c:199
 rcu_gp_cleanup kernel/rcu/tree.c:2046 [inline]
 rcu_gp_kthread+0xe5c/0x19a8 kernel/rcu/tree.c:2119
 kthread+0x174/0x188 kernel/kthread.c:292
 ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:961
BUG: scheduling while atomic: rcu_preempt/10/0x00000002
INFO: lockdep is turned off.
Modules linked in:
Preemption disabled at:
[<ffffd787e7fffec0>] preempt_schedule.part.88+0x20/0x28 kernel/sched/core.c:4706
CPU: 0 PID: 10 Comm: rcu_preempt Not tainted 5.10.0-rc3-next-20201110-00001-gc07b306d7fa5-dirty #23
Hardware name: linux,dummy-virt (DT)
Call trace:
 dump_backtrace+0x0/0x278 arch/arm64/kernel/stacktrace.c:100
 show_stack+0x30/0x80 arch/arm64/kernel/stacktrace.c:196
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x138/0x1b0 lib/dump_stack.c:118
 __schedule_bug+0x8c/0xe8 kernel/sched/core.c:4262
 schedule_debug kernel/sched/core.c:4289 [inline]
 __schedule+0x7e8/0x890 kernel/sched/core.c:4417
 preempt_schedule_common+0x44/0x1b0 kernel/sched/core.c:4681
 preempt_schedule.part.88+0x20/0x28 kernel/sched/core.c:4706
 preempt_schedule+0x20/0x28 kernel/sched/core.c:4707
 __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline]
 _raw_spin_unlock_irq+0x80/0x90 kernel/locking/spinlock.c:199
 rcu_gp_cleanup kernel/rcu/tree.c:2046 [inline]
 rcu_gp_kthread+0xe5c/0x19a8 kernel/rcu/tree.c:2119
 kthread+0x174/0x188 kernel/kthread.c:292
 ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:961

  reply	other threads:[~2020-11-12 18:13 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 13:53 [PATCH] kfence: Avoid stalling work queue task without allocations Marco Elver
2020-11-10 13:53 ` Marco Elver
2020-11-10 14:25 ` Dmitry Vyukov
2020-11-10 14:25   ` Dmitry Vyukov
2020-11-10 14:53   ` Marco Elver
2020-11-10 14:53     ` Marco Elver
2020-11-10 23:23 ` Anders Roxell
2020-11-10 23:23   ` Anders Roxell
2020-11-11  8:29   ` Marco Elver
2020-11-11  8:29     ` Marco Elver
2020-11-11 13:38     ` Marco Elver
2020-11-11 18:05       ` Steven Rostedt
2020-11-11 18:23         ` Paul E. McKenney
2020-11-11 18:34           ` Marco Elver
2020-11-11 19:21             ` Paul E. McKenney
2020-11-11 20:21               ` Marco Elver
2020-11-12  0:11                 ` Paul E. McKenney
2020-11-12 12:49                   ` Marco Elver
2020-11-12 12:49                     ` Marco Elver
2020-11-12 16:14                     ` Marco Elver
2020-11-12 17:54                       ` Paul E. McKenney
2020-11-12 18:12                         ` Marco Elver [this message]
2020-11-12 20:00                           ` Paul E. McKenney
2020-11-13 11:06                             ` Marco Elver
2020-11-13 17:20                               ` Paul E. McKenney
2020-11-13 17:57                         ` Paul E. McKenney
2020-11-17 10:52                           ` Marco Elver
2020-11-17 18:29                             ` Paul E. McKenney
2020-11-18 22:56                               ` Marco Elver
2020-11-18 23:38                                 ` Paul E. McKenney
2020-11-19 12:53                                   ` Marco Elver
2020-11-19 15:14                                     ` Paul E. McKenney
2020-11-19 17:02                                       ` Marco Elver
2020-11-19 18:48                                         ` Paul E. McKenney
2020-11-19 19:38                                           ` linux-next: stall warnings and deadlock on Arm64 (was: [PATCH] kfence: Avoid stalling...) Marco Elver
2020-11-19 19:38                                             ` Marco Elver
2020-11-19 21:35                                             ` Paul E. McKenney
2020-11-19 21:35                                               ` Paul E. McKenney
2020-11-19 22:53                                               ` Will Deacon
2020-11-19 22:53                                                 ` Will Deacon
2020-11-20 10:30                                                 ` Mark Rutland
2020-11-20 10:30                                                   ` Mark Rutland
2020-11-20 14:03                                                   ` Marco Elver
2020-11-20 14:03                                                     ` Marco Elver
2020-11-23 19:32                                                     ` Mark Rutland
2020-11-23 19:32                                                       ` Mark Rutland
2020-11-24 14:03                                                       ` Marco Elver
2020-11-24 14:03                                                         ` Marco Elver
2020-11-24 15:01                                                         ` Paul E. McKenney
2020-11-24 15:01                                                           ` Paul E. McKenney
2020-11-24 19:43                                                           ` Mark Rutland
2020-11-24 19:43                                                             ` Mark Rutland
2020-11-24 20:32                                                             ` Steven Rostedt
2020-11-24 20:32                                                               ` Steven Rostedt
2020-11-24 19:30                                                         ` Mark Rutland
2020-11-24 19:30                                                           ` Mark Rutland
2020-11-25  9:45                                                           ` Marco Elver
2020-11-25  9:45                                                             ` Marco Elver
2020-11-25 10:28                                                             ` Mark Rutland
2020-11-25 10:28                                                               ` Mark Rutland
2020-11-20 14:19                                               ` Marco Elver
2020-11-20 14:19                                                 ` Marco Elver
2020-11-20 14:39                                                 ` Paul E. McKenney
2020-11-20 14:39                                                   ` Paul E. McKenney
2020-11-20 15:22                                                   ` Mark Rutland
2020-11-20 15:22                                                     ` Mark Rutland
2020-11-20 17:38                                                     ` Paul E. McKenney
2020-11-20 17:38                                                       ` Paul E. McKenney
2020-11-20 18:02                                                       ` Mark Rutland
2020-11-20 18:02                                                         ` Mark Rutland
2020-11-20 18:57                                                         ` Paul E. McKenney
2020-11-20 18:57                                                           ` Paul E. McKenney
2020-11-20 15:26                                                 ` Steven Rostedt
2020-11-20 15:26                                                   ` Steven Rostedt
2020-11-20 18:17                                                   ` Marco Elver
2020-11-20 18:17                                                     ` Marco Elver
2020-11-20 18:57                                                     ` Steven Rostedt
2020-11-20 18:57                                                       ` Steven Rostedt
2020-11-20 19:16                                                     ` Steven Rostedt
2020-11-20 19:16                                                       ` Steven Rostedt
2020-11-20 19:22                                                       ` Marco Elver
2020-11-20 19:22                                                         ` Marco Elver
2020-11-20 19:22                                                         ` Marco Elver
2020-11-20 19:27                                     ` [PATCH] kfence: Avoid stalling work queue task without allocations Steven Rostedt
2020-11-23 15:27                                       ` Marco Elver
2020-11-23 16:28                                         ` Steven Rostedt
2020-11-23 16:36                                           ` Steven Rostedt
2020-11-23 18:53                                             ` Marco Elver
2020-11-23 18:42                                           ` Steven Rostedt
2020-11-24  2:59                                             ` Boqun Feng
2020-11-24  3:44                                               ` Paul E. McKenney
2020-11-11 18:21       ` Paul E. McKenney
2020-11-11 15:01     ` Anders Roxell
2020-11-11 15:01       ` Anders Roxell
2020-11-11 15:22       ` Marco Elver
2020-11-11 15:22         ` Marco Elver

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=20201112181254.GA3113918@elver.google.com \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=anders.roxell@linaro.org \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=jannh@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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.