| Message ID | 20220825063154.69-3-thunder.leizhen@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm: Replace this_cpu_* with raw_cpu_* in panic_bad_stack() | expand |
On Thu, Aug 25, 2022 at 02:31:54PM +0800, Zhen Lei wrote: > The hardware automatically disable the IRQ interrupt before jumping to the > interrupt or exception vector. Therefore, the preempt_disable() operation > in this_cpu_read() after macro expansion is unnecessary. In fact, function > this_cpu_read() may trigger scheduling, see pseudocode below. > > Pseudocode of this_cpu_read(xx): > preempt_disable_notrace(); > raw_cpu_read(xx); > if (unlikely(__preempt_count_dec_and_test())) > __preempt_schedule_notrace(); > > Therefore, use raw_cpu_* instead of this_cpu_* to eliminate potential > hazards. At the very least, it reduces a few lines of assembly code. I think if scheduling is a problem here, something should increment the preempt_count as is done on arm64, since any other operation in this function could end up causing preemption. Regardless, I also think it's sensible to use raw_cpu_*() here, but I don't think that actually fixes the problem the commit message describes. Thanks, Mark. > > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > --- > KernelVersion: v6.0-rc2 > arch/arm/kernel/traps.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c > index 1518a1f443ff866..d5903d790cf3b7e 100644 > --- a/arch/arm/kernel/traps.c > +++ b/arch/arm/kernel/traps.c > @@ -927,9 +927,9 @@ asmlinkage void handle_bad_stack(struct pt_regs *regs) > { > unsigned long tsk_stk = (unsigned long)current->stack; > #ifdef CONFIG_IRQSTACKS > - unsigned long irq_stk = (unsigned long)this_cpu_read(irq_stack_ptr); > + unsigned long irq_stk = (unsigned long)raw_cpu_read(irq_stack_ptr); > #endif > - unsigned long ovf_stk = (unsigned long)this_cpu_read(overflow_stack_ptr); > + unsigned long ovf_stk = (unsigned long)raw_cpu_read(overflow_stack_ptr); > > console_verbose(); > pr_emerg("Insufficient stack space to handle exception!"); > -- > 2.25.1 >
On 2022/8/25 21:32, Mark Rutland wrote: > On Thu, Aug 25, 2022 at 02:31:54PM +0800, Zhen Lei wrote: >> The hardware automatically disable the IRQ interrupt before jumping to the >> interrupt or exception vector. Therefore, the preempt_disable() operation >> in this_cpu_read() after macro expansion is unnecessary. In fact, function >> this_cpu_read() may trigger scheduling, see pseudocode below. >> >> Pseudocode of this_cpu_read(xx): >> preempt_disable_notrace(); >> raw_cpu_read(xx); >> if (unlikely(__preempt_count_dec_and_test())) >> __preempt_schedule_notrace(); >> >> Therefore, use raw_cpu_* instead of this_cpu_* to eliminate potential >> hazards. At the very least, it reduces a few lines of assembly code. > > I think if scheduling is a problem here, something should increment the > preempt_count as is done on arm64, since any other operation in this function > could end up causing preemption. Yes, right. Sorry, I'm stuck in this_cpu_read()'s analysis. > > Regardless, I also think it's sensible to use raw_cpu_*() here, but I don't > think that actually fixes the problem the commit message describes. OK, I will delete the description about risk. The risk I mentioned in the commit message was mainly to show that using raw_cpu_read() would be better than using this_cpu_read() in this case. > > Thanks, > Mark. > >> >> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >> --- >> KernelVersion: v6.0-rc2 >> arch/arm/kernel/traps.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c >> index 1518a1f443ff866..d5903d790cf3b7e 100644 >> --- a/arch/arm/kernel/traps.c >> +++ b/arch/arm/kernel/traps.c >> @@ -927,9 +927,9 @@ asmlinkage void handle_bad_stack(struct pt_regs *regs) >> { >> unsigned long tsk_stk = (unsigned long)current->stack; >> #ifdef CONFIG_IRQSTACKS >> - unsigned long irq_stk = (unsigned long)this_cpu_read(irq_stack_ptr); >> + unsigned long irq_stk = (unsigned long)raw_cpu_read(irq_stack_ptr); >> #endif >> - unsigned long ovf_stk = (unsigned long)this_cpu_read(overflow_stack_ptr); >> + unsigned long ovf_stk = (unsigned long)raw_cpu_read(overflow_stack_ptr); >> >> console_verbose(); >> pr_emerg("Insufficient stack space to handle exception!"); >> -- >> 2.25.1 >> > . >
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c index 1518a1f443ff866..d5903d790cf3b7e 100644 --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -927,9 +927,9 @@ asmlinkage void handle_bad_stack(struct pt_regs *regs) { unsigned long tsk_stk = (unsigned long)current->stack; #ifdef CONFIG_IRQSTACKS - unsigned long irq_stk = (unsigned long)this_cpu_read(irq_stack_ptr); + unsigned long irq_stk = (unsigned long)raw_cpu_read(irq_stack_ptr); #endif - unsigned long ovf_stk = (unsigned long)this_cpu_read(overflow_stack_ptr); + unsigned long ovf_stk = (unsigned long)raw_cpu_read(overflow_stack_ptr); console_verbose(); pr_emerg("Insufficient stack space to handle exception!");
The hardware automatically disable the IRQ interrupt before jumping to the interrupt or exception vector. Therefore, the preempt_disable() operation in this_cpu_read() after macro expansion is unnecessary. In fact, function this_cpu_read() may trigger scheduling, see pseudocode below. Pseudocode of this_cpu_read(xx): preempt_disable_notrace(); raw_cpu_read(xx); if (unlikely(__preempt_count_dec_and_test())) __preempt_schedule_notrace(); Therefore, use raw_cpu_* instead of this_cpu_* to eliminate potential hazards. At the very least, it reduces a few lines of assembly code. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> --- KernelVersion: v6.0-rc2 arch/arm/kernel/traps.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)