linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/2] arm: Replace this_cpu_* with raw_cpu_* in panic_bad_stack()
@ 2022-08-26  9:51 Zhen Lei
  2022-08-26  9:51 ` [PATCH v2 1/2] arm64/traps: " Zhen Lei
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Zhen Lei @ 2022-08-26  9:51 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Russell King,
	linux-arm-kernel, linux-kernel, patches
  Cc: Zhen Lei

v1 --> v2:
Update commit message of two patches.

v1:
I'm analyzing a strange problem these days, and I find that there are some areas in
panic_bad_stack() that can be optimized. That is, replace this_cpu_* with raw_cpu_* .

Just optimization, it is unlikely to cause the following exception nesting, because of
"lr : __bad_stack+0x88/0x8c".

[20220819163739]Unable to handle kernel paging request at virtual address f7ffff94901b8048
[20220819163739]Mem abort info:
[20220819163739]  ESR = 0x96000004
[20220819163739]  EC = 0x25: DABT (current EL), IL = 32 bits
[20220819163739]  SET = 0, FnV = 0
[20220819163739]  EA = 0, S1PTW = 0
[20220819163739]Data abort info:
[20220819163739]  ISV = 0, ISS = 0x00000004
[20220819163739]  CM = 0, WnR = 0
[20220819163739][f7ffff94901b8048] address between user and kernel address ranges
[20220819163739]Internal error: Oops: 96000004 [#1] PREEMPT SMP
[20220819163739]Modules linked in: ...
[20220819163740]CPU: 2 PID: 1272 Comm: 00002SWDLMain Tainted: G        W  O      5.10.0 #1
[20220819163740]Hardware name: hisilicon,hi1213-fpga (DT)
[20220819163740]pstate: 000003c5 (nzcv DAIF -PAN -UAO -TCO BTYPE=--)
[20220819163740]pc : __bad_stack+0x4c/0x8c
[20220819163740]lr : __bad_stack+0x88/0x8c
[20220819163740]sp : ffffff953ffa8160
[20220819163740]x29: f7ffff953ffa8120 x28: f7ffff94901b8040 
[20220819163740]x27: ffffffeb72ea6940 x26: ffffffebeee6cf10 
[20220819163740]x25: ffffffebef627000 x24: 0000000000000000 
[20220819163740]x23: 00000000600003c5 x22: f7ffffebeee11904 
[20220819163740]x21: ffffff953ffa82b0 x20: 0000007fffffffff 
[20220819163740]x19: f7ffffc0133ab898 x18: 0000000000000000 
[20220819163740]x17: 0000000000000000 x16: ffffffebef32f0a0 
[20220819163740]x15: 00000000624057a0 x14: 953325a7da350fb3 
[20220819163740]x13: 09bbbe32ce2b3c11 x12: c15a0e2d1991997b 
[20220819163740]x11: 0bc8be839e7850d0 x10: cafa1cb223203045 
[20220819163740]x9 : f36bed299e5840dc x8 : ffffffc0133aba48 
[20220819163740]x7 : ffffff953b1b0480 x6 : ffffffebef3e1000 
[20220819163740]x5 : 0000000000000000 x4 : 0000000000000001 
[20220819163740]x3 : f7ffffc0133ab750 x2 : 0000000000000025 
[20220819163740]x1 : 0000000096000004 x0 : ffffff953ffa8160 
[20220819163740]Call trace:
[20220819163740] __bad_stack+0x4c/0x8c
[20220819163740]Code: a90d6ffa a90e77fc 910543f5 d538411c (f9400794) 
[20220819163740]---[ end trace 07532bfa2c24851c ]---
[20220819163740]Kernel panic - not syncing: Oops: Fatal exception

Zhen Lei (2):
  arm64/traps: Replace this_cpu_* with raw_cpu_* in panic_bad_stack()
  ARM: replace this_cpu_* with raw_cpu_* in panic_bad_stack()

 arch/arm/kernel/traps.c   | 4 ++--
 arch/arm64/kernel/traps.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.25.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH v2 1/2] arm64/traps: Replace this_cpu_* with raw_cpu_* in panic_bad_stack()
  2022-08-26  9:51 [PATCH v2 0/2] arm: Replace this_cpu_* with raw_cpu_* in panic_bad_stack() Zhen Lei
@ 2022-08-26  9:51 ` Zhen Lei
  2022-08-26  9:51 ` [PATCH v2 2/2] ARM: replace " Zhen Lei
  2022-09-07 14:13 ` [PATCH v2 0/2] arm: Replace " Russell King (Oracle)
  2 siblings, 0 replies; 5+ messages in thread
From: Zhen Lei @ 2022-08-26  9:51 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Russell King,
	linux-arm-kernel, linux-kernel, patches
  Cc: Zhen Lei

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 for exception
handler. Use raw_cpu_* instead of this_cpu_* can reduce a few lines of
assembly code. To be honest, the fewer unnecessary operations in exception
handler, the better.

Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 arch/arm64/kernel/traps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index b7fed33981f7b76..e6b6f4650e3d895 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -871,8 +871,8 @@ DEFINE_PER_CPU(unsigned long [OVERFLOW_STACK_SIZE/sizeof(long)], overflow_stack)
 void panic_bad_stack(struct pt_regs *regs, unsigned long esr, unsigned long far)
 {
 	unsigned long tsk_stk = (unsigned long)current->stack;
-	unsigned long irq_stk = (unsigned long)this_cpu_read(irq_stack_ptr);
-	unsigned long ovf_stk = (unsigned long)this_cpu_ptr(overflow_stack);
+	unsigned long irq_stk = (unsigned long)raw_cpu_read(irq_stack_ptr);
+	unsigned long ovf_stk = (unsigned long)raw_cpu_ptr(overflow_stack);
 
 	console_verbose();
 	pr_emerg("Insufficient stack space to handle exception!");
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH v2 2/2] ARM: replace this_cpu_* with raw_cpu_* in panic_bad_stack()
  2022-08-26  9:51 [PATCH v2 0/2] arm: Replace this_cpu_* with raw_cpu_* in panic_bad_stack() Zhen Lei
  2022-08-26  9:51 ` [PATCH v2 1/2] arm64/traps: " Zhen Lei
@ 2022-08-26  9:51 ` Zhen Lei
  2022-09-07 14:13 ` [PATCH v2 0/2] arm: Replace " Russell King (Oracle)
  2 siblings, 0 replies; 5+ messages in thread
From: Zhen Lei @ 2022-08-26  9:51 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Russell King,
	linux-arm-kernel, linux-kernel, patches
  Cc: Zhen Lei

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 for exception
handler. Use raw_cpu_* instead of this_cpu_* can reduce a few lines of
assembly code. To be honest, the fewer unnecessary operations in exception
handler, the better.

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


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v2 0/2] arm: Replace this_cpu_* with raw_cpu_* in panic_bad_stack()
  2022-08-26  9:51 [PATCH v2 0/2] arm: Replace this_cpu_* with raw_cpu_* in panic_bad_stack() Zhen Lei
  2022-08-26  9:51 ` [PATCH v2 1/2] arm64/traps: " Zhen Lei
  2022-08-26  9:51 ` [PATCH v2 2/2] ARM: replace " Zhen Lei
@ 2022-09-07 14:13 ` Russell King (Oracle)
  2022-09-08  1:47   ` Leizhen (ThunderTown)
  2 siblings, 1 reply; 5+ messages in thread
From: Russell King (Oracle) @ 2022-09-07 14:13 UTC (permalink / raw)
  To: Zhen Lei
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, linux-arm-kernel,
	linux-kernel, patches

Please distinguish your patches/patch series between arch/arm and
arch/arm64. The two are maintained separately, and it gets quite
annoying to read messages nd then realise that they're not for 32-bit
ARM, but are for arm64/aarch64.

Thanks.

On Fri, Aug 26, 2022 at 05:51:10PM +0800, Zhen Lei wrote:
> v1 --> v2:
> Update commit message of two patches.
> 
> v1:
> I'm analyzing a strange problem these days, and I find that there are some areas in
> panic_bad_stack() that can be optimized. That is, replace this_cpu_* with raw_cpu_* .
> 
> Just optimization, it is unlikely to cause the following exception nesting, because of
> "lr : __bad_stack+0x88/0x8c".
> 
> [20220819163739]Unable to handle kernel paging request at virtual address f7ffff94901b8048
> [20220819163739]Mem abort info:
> [20220819163739]  ESR = 0x96000004
> [20220819163739]  EC = 0x25: DABT (current EL), IL = 32 bits
> [20220819163739]  SET = 0, FnV = 0
> [20220819163739]  EA = 0, S1PTW = 0
> [20220819163739]Data abort info:
> [20220819163739]  ISV = 0, ISS = 0x00000004
> [20220819163739]  CM = 0, WnR = 0
> [20220819163739][f7ffff94901b8048] address between user and kernel address ranges
> [20220819163739]Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [20220819163739]Modules linked in: ...
> [20220819163740]CPU: 2 PID: 1272 Comm: 00002SWDLMain Tainted: G        W  O      5.10.0 #1
> [20220819163740]Hardware name: hisilicon,hi1213-fpga (DT)
> [20220819163740]pstate: 000003c5 (nzcv DAIF -PAN -UAO -TCO BTYPE=--)
> [20220819163740]pc : __bad_stack+0x4c/0x8c
> [20220819163740]lr : __bad_stack+0x88/0x8c
> [20220819163740]sp : ffffff953ffa8160
> [20220819163740]x29: f7ffff953ffa8120 x28: f7ffff94901b8040 
> [20220819163740]x27: ffffffeb72ea6940 x26: ffffffebeee6cf10 
> [20220819163740]x25: ffffffebef627000 x24: 0000000000000000 
> [20220819163740]x23: 00000000600003c5 x22: f7ffffebeee11904 
> [20220819163740]x21: ffffff953ffa82b0 x20: 0000007fffffffff 
> [20220819163740]x19: f7ffffc0133ab898 x18: 0000000000000000 
> [20220819163740]x17: 0000000000000000 x16: ffffffebef32f0a0 
> [20220819163740]x15: 00000000624057a0 x14: 953325a7da350fb3 
> [20220819163740]x13: 09bbbe32ce2b3c11 x12: c15a0e2d1991997b 
> [20220819163740]x11: 0bc8be839e7850d0 x10: cafa1cb223203045 
> [20220819163740]x9 : f36bed299e5840dc x8 : ffffffc0133aba48 
> [20220819163740]x7 : ffffff953b1b0480 x6 : ffffffebef3e1000 
> [20220819163740]x5 : 0000000000000000 x4 : 0000000000000001 
> [20220819163740]x3 : f7ffffc0133ab750 x2 : 0000000000000025 
> [20220819163740]x1 : 0000000096000004 x0 : ffffff953ffa8160 
> [20220819163740]Call trace:
> [20220819163740] __bad_stack+0x4c/0x8c
> [20220819163740]Code: a90d6ffa a90e77fc 910543f5 d538411c (f9400794) 
> [20220819163740]---[ end trace 07532bfa2c24851c ]---
> [20220819163740]Kernel panic - not syncing: Oops: Fatal exception
> 
> Zhen Lei (2):
>   arm64/traps: Replace this_cpu_* with raw_cpu_* in panic_bad_stack()
>   ARM: replace this_cpu_* with raw_cpu_* in panic_bad_stack()
> 
>  arch/arm/kernel/traps.c   | 4 ++--
>  arch/arm64/kernel/traps.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> -- 
> 2.25.1
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2 0/2] arm: Replace this_cpu_* with raw_cpu_* in panic_bad_stack()
  2022-09-07 14:13 ` [PATCH v2 0/2] arm: Replace " Russell King (Oracle)
@ 2022-09-08  1:47   ` Leizhen (ThunderTown)
  0 siblings, 0 replies; 5+ messages in thread
From: Leizhen (ThunderTown) @ 2022-09-08  1:47 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, linux-arm-kernel,
	linux-kernel, patches



On 2022/9/7 22:13, Russell King (Oracle) wrote:
> Please distinguish your patches/patch series between arch/arm and
> arch/arm64. The two are maintained separately, and it gets quite
> annoying to read messages nd then realise that they're not for 32-bit
> ARM, but are for arm64/aarch64.

OK, I'm sorry for causing you any trouble.

> 
> Thanks.
> 
> On Fri, Aug 26, 2022 at 05:51:10PM +0800, Zhen Lei wrote:
>> v1 --> v2:
>> Update commit message of two patches.
>>
>> v1:
>> I'm analyzing a strange problem these days, and I find that there are some areas in
>> panic_bad_stack() that can be optimized. That is, replace this_cpu_* with raw_cpu_* .
>>
>> Just optimization, it is unlikely to cause the following exception nesting, because of
>> "lr : __bad_stack+0x88/0x8c".
>>
>> [20220819163739]Unable to handle kernel paging request at virtual address f7ffff94901b8048
>> [20220819163739]Mem abort info:
>> [20220819163739]  ESR = 0x96000004
>> [20220819163739]  EC = 0x25: DABT (current EL), IL = 32 bits
>> [20220819163739]  SET = 0, FnV = 0
>> [20220819163739]  EA = 0, S1PTW = 0
>> [20220819163739]Data abort info:
>> [20220819163739]  ISV = 0, ISS = 0x00000004
>> [20220819163739]  CM = 0, WnR = 0
>> [20220819163739][f7ffff94901b8048] address between user and kernel address ranges
>> [20220819163739]Internal error: Oops: 96000004 [#1] PREEMPT SMP
>> [20220819163739]Modules linked in: ...
>> [20220819163740]CPU: 2 PID: 1272 Comm: 00002SWDLMain Tainted: G        W  O      5.10.0 #1
>> [20220819163740]Hardware name: hisilicon,hi1213-fpga (DT)
>> [20220819163740]pstate: 000003c5 (nzcv DAIF -PAN -UAO -TCO BTYPE=--)
>> [20220819163740]pc : __bad_stack+0x4c/0x8c
>> [20220819163740]lr : __bad_stack+0x88/0x8c
>> [20220819163740]sp : ffffff953ffa8160
>> [20220819163740]x29: f7ffff953ffa8120 x28: f7ffff94901b8040 
>> [20220819163740]x27: ffffffeb72ea6940 x26: ffffffebeee6cf10 
>> [20220819163740]x25: ffffffebef627000 x24: 0000000000000000 
>> [20220819163740]x23: 00000000600003c5 x22: f7ffffebeee11904 
>> [20220819163740]x21: ffffff953ffa82b0 x20: 0000007fffffffff 
>> [20220819163740]x19: f7ffffc0133ab898 x18: 0000000000000000 
>> [20220819163740]x17: 0000000000000000 x16: ffffffebef32f0a0 
>> [20220819163740]x15: 00000000624057a0 x14: 953325a7da350fb3 
>> [20220819163740]x13: 09bbbe32ce2b3c11 x12: c15a0e2d1991997b 
>> [20220819163740]x11: 0bc8be839e7850d0 x10: cafa1cb223203045 
>> [20220819163740]x9 : f36bed299e5840dc x8 : ffffffc0133aba48 
>> [20220819163740]x7 : ffffff953b1b0480 x6 : ffffffebef3e1000 
>> [20220819163740]x5 : 0000000000000000 x4 : 0000000000000001 
>> [20220819163740]x3 : f7ffffc0133ab750 x2 : 0000000000000025 
>> [20220819163740]x1 : 0000000096000004 x0 : ffffff953ffa8160 
>> [20220819163740]Call trace:
>> [20220819163740] __bad_stack+0x4c/0x8c
>> [20220819163740]Code: a90d6ffa a90e77fc 910543f5 d538411c (f9400794) 
>> [20220819163740]---[ end trace 07532bfa2c24851c ]---
>> [20220819163740]Kernel panic - not syncing: Oops: Fatal exception
>>
>> Zhen Lei (2):
>>   arm64/traps: Replace this_cpu_* with raw_cpu_* in panic_bad_stack()
>>   ARM: replace this_cpu_* with raw_cpu_* in panic_bad_stack()
>>
>>  arch/arm/kernel/traps.c   | 4 ++--
>>  arch/arm64/kernel/traps.c | 4 ++--
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> -- 
>> 2.25.1
>>
>>
> 

-- 
Regards,
  Zhen Lei

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-09-08  1:47 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-26  9:51 [PATCH v2 0/2] arm: Replace this_cpu_* with raw_cpu_* in panic_bad_stack() Zhen Lei
2022-08-26  9:51 ` [PATCH v2 1/2] arm64/traps: " Zhen Lei
2022-08-26  9:51 ` [PATCH v2 2/2] ARM: replace " Zhen Lei
2022-09-07 14:13 ` [PATCH v2 0/2] arm: Replace " Russell King (Oracle)
2022-09-08  1:47   ` Leizhen (ThunderTown)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).