| Message ID | 20220707110511.52129-2-zhengqi.arch@bytedance.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: run softirqs on the per-CPU IRQ stack | expand |
On Thu, Jul 7, 2022 at 1:05 PM Qi Zheng <zhengqi.arch@bytedance.com> wrote: > > Currently arm64 supports per-CPU IRQ stack, but softirqs > are still handled in the task context. > > Since any call to local_bh_enable() at any level in the task's > call stack may trigger a softirq processing run, which could > potentially cause a task stack overflow if the combined stack > footprints exceed the stack's size, let's run these softirqs > on the IRQ stack as well. > > Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com> I think this is the correct approach, but your patch conflicts with another patch I have queued up in the asm-generic tree, see https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git/commit/?h=asm-generic&id=f2c5092190f21 Please adapt accordingly. Are there any architectures left that use IRQ stacks but don't set HAVE_SOFTIRQ_ON_OWN_STACK? If not, we could also consider removing the Kconfig symbol and just requiring it to be done this way (for non-PREEMPT_RT). Arnd
On 2022/7/7 20:58, Arnd Bergmann wrote: > On Thu, Jul 7, 2022 at 1:05 PM Qi Zheng <zhengqi.arch@bytedance.com> wrote: >> >> Currently arm64 supports per-CPU IRQ stack, but softirqs >> are still handled in the task context. >> >> Since any call to local_bh_enable() at any level in the task's >> call stack may trigger a softirq processing run, which could >> potentially cause a task stack overflow if the combined stack >> footprints exceed the stack's size, let's run these softirqs >> on the IRQ stack as well. >> >> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com> > > I think this is the correct approach, but your patch conflicts with another > patch I have queued up in the asm-generic tree, see > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git/commit/?h=asm-generic&id=f2c5092190f21 > > Please adapt accordingly. OK, will do in the next version. > > Are there any architectures left that use IRQ stacks but don't > set HAVE_SOFTIRQ_ON_OWN_STACK? If not, we could > also consider removing the Kconfig symbol and just requiring > it to be done this way (for non-PREEMPT_RT). I haven't taken a close look at other architectures than x86 and arm, but I think it's a good idea. Thanks, Qi > > Arnd
On Thu, Jul 7, 2022 at 3:43 PM Qi Zheng <zhengqi.arch@bytedance.com> wrote: > On 2022/7/7 20:58, Arnd Bergmann wrote: > > On Thu, Jul 7, 2022 at 1:05 PM Qi Zheng <zhengqi.arch@bytedance.com> wrote: > > Are there any architectures left that use IRQ stacks but don't > > set HAVE_SOFTIRQ_ON_OWN_STACK? If not, we could > > also consider removing the Kconfig symbol and just requiring > > it to be done this way (for non-PREEMPT_RT). > > I haven't taken a close look at other architectures than x86 and arm, > but I think it's a good idea. I had another look in the meantime, and I think it's only mips and loongarch now that don't use HAVE_SOFTIRQ_ON_OWN_STACK. Not sure about arch/um/, which is a bit different from the rest. Arnd
On 2022/7/7 21:53, Arnd Bergmann wrote: > On Thu, Jul 7, 2022 at 3:43 PM Qi Zheng <zhengqi.arch@bytedance.com> wrote: >> On 2022/7/7 20:58, Arnd Bergmann wrote: >>> On Thu, Jul 7, 2022 at 1:05 PM Qi Zheng <zhengqi.arch@bytedance.com> wrote: >>> Are there any architectures left that use IRQ stacks but don't >>> set HAVE_SOFTIRQ_ON_OWN_STACK? If not, we could >>> also consider removing the Kconfig symbol and just requiring >>> it to be done this way (for non-PREEMPT_RT). >> >> I haven't taken a close look at other architectures than x86 and arm, >> but I think it's a good idea. > > I had another look in the meantime, and I think it's only mips and loongarch > now that don't use HAVE_SOFTIRQ_ON_OWN_STACK. Not sure about > arch/um/, which is a bit different from the rest. I just glanced at arch/um/, and it's really different from the rest: * Unlike i386, UML doesn't receive IRQs on the normal kernel stack * and switch over to the IRQ stack after some preparation. > > Arnd
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3491d0d99891..402e16fec02a 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -230,6 +230,7 @@ config ARM64 select HAVE_ARCH_USERFAULTFD_MINOR if USERFAULTFD select TRACE_IRQFLAGS_SUPPORT select TRACE_IRQFLAGS_NMI_SUPPORT + select HAVE_SOFTIRQ_ON_OWN_STACK help ARM 64-bit (AArch64) Linux support. diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c index bda49430c9ea..e6aa37672fd4 100644 --- a/arch/arm64/kernel/irq.c +++ b/arch/arm64/kernel/irq.c @@ -22,6 +22,7 @@ #include <linux/vmalloc.h> #include <asm/daifflags.h> #include <asm/vmap_stack.h> +#include <asm/exception.h> /* Only access this in an NMI enter/exit */ DEFINE_PER_CPU(struct nmi_ctx, nmi_contexts); @@ -71,6 +72,16 @@ static void init_irq_stacks(void) } #endif +static void ____do_softirq(struct pt_regs *regs) +{ + __do_softirq(); +} + +void do_softirq_own_stack(void) +{ + call_on_irq_stack(NULL, ____do_softirq); +} + static void default_handle_irq(struct pt_regs *regs) { panic("IRQ taken without a root IRQ handler\n");
Currently arm64 supports per-CPU IRQ stack, but softirqs are still handled in the task context. Since any call to local_bh_enable() at any level in the task's call stack may trigger a softirq processing run, which could potentially cause a task stack overflow if the combined stack footprints exceed the stack's size, let's run these softirqs on the IRQ stack as well. Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com> --- arch/arm64/Kconfig | 1 + arch/arm64/kernel/irq.c | 11 +++++++++++ 2 files changed, 12 insertions(+)