On 2022-06-14 12:07:48 [+0200], Arnd Bergmann wrote: > > So where do I put this patch to? If I remember correctly then arm64 is > > using this. ARM has its own thing and x86 has this change already. > > I don't see HAVE_SOFTIRQ_ON_OWN_STACK for arm, parisc, powerpc, > s390, sh, sparc and x86, but not arm64. I would suggest having a single > patch that does the same change across all architectures that don't already do > this, and then merging it either through tip or through my asm-generic tree. Oh. I posted the ARM bits with my other ARM patch as a mini two patch series a few secs before this. I could group this softirq change for all architectures in a single patch. But then powerpc didn't want the "PREEMPT_RT" annotation for the warning/ stack backtrace and they may not be too keen about this. So for powerpc I was thinking to present them all at once. Looking at sparc and parisc, there might be more to it than just this. Both were never tested while I have the missing bits for arm* and powerpc in my queue. Eitherway, if you want I can regroup and send you the softirq bits for all arches. > > - ksoftirqd thread. > > - in the force-threaded interrupt after the main handler. > > - any time after bh-counter hits zero due local_bh_enable(). > > > > The last one will cause higher task stacks. > > Does this mean it only happens when a softirq gets raised from task context > (which would be predictable), or also at an arbitrary time if it gets raised > by a non-threaded hardirq or IPI? If the softirq gets raised from non-task context (hardirq or IPI) then it will be deferred to ksoftirqd (and not invoked on irq-exit path). > Arnd Sebastian
