On Fri, Feb 19, 2021 at 02:43:34PM +0800, Wen Yang wrote: > From: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > > commit 19dbdcb8039cff16669a05136a29180778d16d0a upstream. > > It's clearly documented that smp function calls cannot be invoked from > softirq handling context. Unfortunately nothing enforces that or emits a > warning. > > A single function call can be invoked from softirq context only via > smp_call_function_single_async(). > > The only legit context is task context, so add a warning to that effect. > > Reported-by: luferry <luferry@xxxxxxx> > Signed-off-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Link: https://lkml.kernel.org/r/20190718160601.GP3402@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Cc: stable <stable@xxxxxxxxxxxxxxx> # 4.9.x > Signed-off-by: Wen Yang <simon.wy@xxxxxxxxxxxxxxx> > --- > kernel/smp.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/kernel/smp.c b/kernel/smp.c > index 399905f..f2b29c4 100644 > --- a/kernel/smp.c > +++ b/kernel/smp.c > @@ -276,6 +276,14 @@ int smp_call_function_single(int cpu, smp_call_func_t func, void *info, > WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() > && !oops_in_progress); > > + /* > + * When @wait we can deadlock when we interrupt between llist_add() and > + * arch_send_call_function_ipi*(); when !@wait we can deadlock due to > + * csd_lock() on because the interrupt context uses the same csd > + * storage. > + */ > + WARN_ON_ONCE(!in_task()); > + > csd = &csd_stack; > if (!wait) { > csd = this_cpu_ptr(&csd_data); > @@ -401,6 +409,14 @@ void smp_call_function_many(const struct cpumask *mask, > WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() > && !oops_in_progress && !early_boot_irqs_disabled); > > + /* > + * When @wait we can deadlock when we interrupt between llist_add() and > + * arch_send_call_function_ipi*(); when !@wait we can deadlock due to > + * csd_lock() on because the interrupt context uses the same csd > + * storage. > + */ > + WARN_ON_ONCE(!in_task()); > + > /* Try to fastpath. So, what's a CPU they want? Ignoring this one. */ > cpu = cpumask_first_and(mask, cpu_online_mask); > if (cpu == this_cpu) > -- > 1.8.3.1 > WHy do you want this in the 4.9.y kernel tree only, and not all others? What bug/problem does this fix? It seems that it will only report problems that other code has, not fix existing code. If anything, it's going to start causing machines to reboot that have "panic on warn" set, is that a good thing to do? thanks, greg k-h
