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(-)

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 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
>>
> .
> 

-- 
Regards,
  Zhen Lei