* [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick()
@ 2022-11-19 4:00 Zheng Yejian
2022-11-21 19:57 ` Paul E. McKenney
0 siblings, 1 reply; 7+ messages in thread
From: Zheng Yejian @ 2022-11-19 4:00 UTC (permalink / raw)
To: paulmck, frederic, quic_neeraju, josh, rostedt, mathieu.desnoyers,
jiangshanlai, joel, rcu, linux-kernel
Cc: zhengyejian1
Register kprobe on __rcu_irq_enter_check_tick() can cause kernel stack
overflow [1]. This issue is first found in v5.10 and can be reproduced
by enabling CONFIG_NO_HZ_FULL and doing like:
# cd /sys/kernel/debug/tracing/
# echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
# echo 1 > events/kprobes/enable
So __rcu_irq_enter_check_tick() should not be kprobed, mark it as noinstr.
[1]
Insufficient stack space to handle exception!
Insufficient stack space to handle exception!
[...]
Kernel panic - not syncing: kernel stack overflow
CPU: 3 PID: 34 Comm: migration/3 Not tainted
6.1.0-rc5-00884-g84368d882b96 #2
Hardware name: linux,dummy-virt (DT)
Stopper: multi_cpu_stop+0x0/0x228 <- __stop_cpus.constprop.0+0xa4/0x100
Call trace:
dump_backtrace+0xf8/0x108
show_stack+0x20/0x48
dump_stack_lvl+0x68/0x84
dump_stack+0x1c/0x38
panic+0x214/0x404
add_taint+0x0/0xf0
panic_bad_stack+0x144/0x160
handle_bad_stack+0x38/0x58
__bad_stack+0x78/0x7c
el1h_64_sync_handler+0x4/0xe8
__rcu_irq_enter_check_tick+0x0/0x1b8
arm64_enter_el1_dbg.isra.0+0x14/0x20
el1_dbg+0x2c/0x90
el1h_64_sync_handler+0xcc/0xe8
el1h_64_sync+0x64/0x68
__rcu_irq_enter_check_tick+0x0/0x1b8
arm64_enter_el1_dbg.isra.0+0x14/0x20
el1_dbg+0x2c/0x90
el1h_64_sync_handler+0xcc/0xe8
el1h_64_sync+0x64/0x68
__rcu_irq_enter_check_tick+0x0/0x1b8
arm64_enter_el1_dbg.isra.0+0x14/0x20
el1_dbg+0x2c/0x90
el1h_64_sync_handler+0xcc/0xe8
el1h_64_sync+0x64/0x68
__rcu_irq_enter_check_tick+0x0/0x1b8
arm64_enter_el1_dbg.isra.0+0x14/0x20
el1_dbg+0x2c/0x90
el1h_64_sync_handler+0xcc/0xe8
el1h_64_sync+0x64/0x68
__rcu_irq_enter_check_tick+0x0/0x1b8
arm64_enter_el1_dbg.isra.0+0x14/0x20
el1_dbg+0x2c/0x90
el1h_64_sync_handler+0xcc/0xe8
el1h_64_sync+0x64/0x68
__rcu_irq_enter_check_tick+0x0/0x1b8
[...]
Cc: stable@vger.kernel.org
Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
---
kernel/rcu/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 93416afebd59..68230f02cfb7 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -631,7 +631,7 @@ void rcu_irq_exit_check_preempt(void)
* controlled environments, this function allows RCU to get what it
* needs without creating otherwise useless interruptions.
*/
-void __rcu_irq_enter_check_tick(void)
+noinstr void __rcu_irq_enter_check_tick(void)
{
struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
--
2.25.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick()
2022-11-19 4:00 [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick() Zheng Yejian
@ 2022-11-21 19:57 ` Paul E. McKenney
2022-12-02 9:54 ` Zheng Yejian
2022-12-05 13:23 ` Frederic Weisbecker
0 siblings, 2 replies; 7+ messages in thread
From: Paul E. McKenney @ 2022-11-21 19:57 UTC (permalink / raw)
To: Zheng Yejian
Cc: frederic, quic_neeraju, josh, rostedt, mathieu.desnoyers,
jiangshanlai, joel, rcu, linux-kernel
On Sat, Nov 19, 2022 at 12:00:49PM +0800, Zheng Yejian wrote:
> Register kprobe on __rcu_irq_enter_check_tick() can cause kernel stack
> overflow [1]. This issue is first found in v5.10 and can be reproduced
> by enabling CONFIG_NO_HZ_FULL and doing like:
> # cd /sys/kernel/debug/tracing/
> # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
> # echo 1 > events/kprobes/enable
>
> So __rcu_irq_enter_check_tick() should not be kprobed, mark it as noinstr.
Good catch!
I am inclined to queue this, but noticed that one of its callers need
it to be noinstr but that the others do not.
Need noinstr:
o enter_from_kernel_mode() -> __enter_from_kernel_mode() ->
rcu_irq_enter_check_tick() -> __rcu_irq_enter_check_tick()
Doesn't need noinstr:
o ct_nmi_enter() -> rcu_irq_enter_check_tick() ->
__rcu_irq_enter_check_tick(), courtesy of the call to
instrumentation_begin() in ct_nmi_enter() that precedes the call
to rcu_irq_enter_check_tick().
o irqentry_enter() -> rcu_irq_enter_check_tick() ->
__rcu_irq_enter_check_tick(), courtesy of the call to
instrumentation_begin() in irqentry_enter() that precedes the
call to rcu_irq_enter_check_tick().
Is tagging __rcu_irq_enter_check_tick() with noinstr as
proposed in this patch the right thing to do, or should there
be calls to instrumentation_begin() and instrumentation_end() in
enter_from_kernel_mode()? Or something else entirely?
Thoughts?
Thanx, Paul
> [1]
> Insufficient stack space to handle exception!
> Insufficient stack space to handle exception!
> [...]
> Kernel panic - not syncing: kernel stack overflow
> CPU: 3 PID: 34 Comm: migration/3 Not tainted
> 6.1.0-rc5-00884-g84368d882b96 #2
> Hardware name: linux,dummy-virt (DT)
> Stopper: multi_cpu_stop+0x0/0x228 <- __stop_cpus.constprop.0+0xa4/0x100
> Call trace:
> dump_backtrace+0xf8/0x108
> show_stack+0x20/0x48
> dump_stack_lvl+0x68/0x84
> dump_stack+0x1c/0x38
> panic+0x214/0x404
> add_taint+0x0/0xf0
> panic_bad_stack+0x144/0x160
> handle_bad_stack+0x38/0x58
> __bad_stack+0x78/0x7c
> el1h_64_sync_handler+0x4/0xe8
> __rcu_irq_enter_check_tick+0x0/0x1b8
> arm64_enter_el1_dbg.isra.0+0x14/0x20
> el1_dbg+0x2c/0x90
> el1h_64_sync_handler+0xcc/0xe8
> el1h_64_sync+0x64/0x68
> __rcu_irq_enter_check_tick+0x0/0x1b8
> arm64_enter_el1_dbg.isra.0+0x14/0x20
> el1_dbg+0x2c/0x90
> el1h_64_sync_handler+0xcc/0xe8
> el1h_64_sync+0x64/0x68
> __rcu_irq_enter_check_tick+0x0/0x1b8
> arm64_enter_el1_dbg.isra.0+0x14/0x20
> el1_dbg+0x2c/0x90
> el1h_64_sync_handler+0xcc/0xe8
> el1h_64_sync+0x64/0x68
> __rcu_irq_enter_check_tick+0x0/0x1b8
> arm64_enter_el1_dbg.isra.0+0x14/0x20
> el1_dbg+0x2c/0x90
> el1h_64_sync_handler+0xcc/0xe8
> el1h_64_sync+0x64/0x68
> __rcu_irq_enter_check_tick+0x0/0x1b8
> arm64_enter_el1_dbg.isra.0+0x14/0x20
> el1_dbg+0x2c/0x90
> el1h_64_sync_handler+0xcc/0xe8
> el1h_64_sync+0x64/0x68
> __rcu_irq_enter_check_tick+0x0/0x1b8
> [...]
>
> Cc: stable@vger.kernel.org
> Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
> Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
> ---
> kernel/rcu/tree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 93416afebd59..68230f02cfb7 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -631,7 +631,7 @@ void rcu_irq_exit_check_preempt(void)
> * controlled environments, this function allows RCU to get what it
> * needs without creating otherwise useless interruptions.
> */
> -void __rcu_irq_enter_check_tick(void)
> +noinstr void __rcu_irq_enter_check_tick(void)
> {
> struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick()
2022-11-21 19:57 ` Paul E. McKenney
@ 2022-12-02 9:54 ` Zheng Yejian
2022-12-02 19:24 ` Paul E. McKenney
2022-12-05 15:35 ` Frederic Weisbecker
2022-12-05 13:23 ` Frederic Weisbecker
1 sibling, 2 replies; 7+ messages in thread
From: Zheng Yejian @ 2022-12-02 9:54 UTC (permalink / raw)
To: paulmck
Cc: frederic, quic_neeraju, josh, rostedt, mathieu.desnoyers,
jiangshanlai, joel, rcu, linux-kernel
On 2022/11/22 03:57, Paul E. McKenney wrote:
> On Sat, Nov 19, 2022 at 12:00:49PM +0800, Zheng Yejian wrote:
>> Register kprobe on __rcu_irq_enter_check_tick() can cause kernel stack
>> overflow [1]. This issue is first found in v5.10 and can be reproduced
>> by enabling CONFIG_NO_HZ_FULL and doing like:
>> # cd /sys/kernel/debug/tracing/
>> # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
>> # echo 1 > events/kprobes/enable
>>
>> So __rcu_irq_enter_check_tick() should not be kprobed, mark it as noinstr.
>
> Good catch!
>
> I am inclined to queue this, but noticed that one of its callers need
> it to be noinstr but that the others do not.
>
> Need noinstr:
>
> o enter_from_kernel_mode() -> __enter_from_kernel_mode() ->
> rcu_irq_enter_check_tick() -> __rcu_irq_enter_check_tick()
>
> Doesn't need noinstr:
>
> o ct_nmi_enter() -> rcu_irq_enter_check_tick() ->
> __rcu_irq_enter_check_tick(), courtesy of the call to
> instrumentation_begin() in ct_nmi_enter() that precedes the call
> to rcu_irq_enter_check_tick().
>
> o irqentry_enter() -> rcu_irq_enter_check_tick() ->
> __rcu_irq_enter_check_tick(), courtesy of the call to
> instrumentation_begin() in irqentry_enter() that precedes the
> call to rcu_irq_enter_check_tick().
>
> Is tagging __rcu_irq_enter_check_tick() with noinstr as
> proposed in this patch the right thing to do, or should there
> be calls to instrumentation_begin() and instrumentation_end() in
> enter_from_kernel_mode()? Or something else entirely?
I have tried the calls to instrumentation_{begin,end}() in
enter_from_kernel_mode(), see [1]. But this problem can still be
reproduced, maybe more complete calltrace info [2] is needed for
analyzing.
Did I add the instrumentation_{begin,end}() in wrong place or is there
other caller need noinstr?
[1]
diff --git a/arch/arm64/kernel/entry-common.c
b/arch/arm64/kernel/entry-common.c
index 27369fa1c032..deed5a0941d3 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -49,7 +49,9 @@ static __always_inline void
__enter_from_kernel_mode(struct pt_regs *regs)
}
lockdep_hardirqs_off(CALLER_ADDR0);
+ instrumentation_begin();
rcu_irq_enter_check_tick();
+ instrumentation_end();
trace_hardirqs_off_finish();
}
[2]
[ 48.921197] Call trace:
[ 48.921241] dump_backtrace+0xf8/0x108
[ 48.921358] show_stack+0x20/0x48
[ 48.921418] dump_stack_lvl+0x68/0x84
[ 48.921477] dump_stack+0x1c/0x38
[ 48.921530] panic+0x214/0x404
[ 48.921598] add_taint+0x0/0xf0
[ 48.921657] panic_bad_stack+0x144/0x160
[ 48.921715] handle_bad_stack+0x38/0x58
[ 48.921774] __bad_stack+0x78/0x7c
[ 48.921825] __rcu_irq_enter_check_tick+0x0/0x1b8
[ 48.921886] arm64_enter_el1_dbg.isra.0+0x14/0x20
[ 48.921949] el1_dbg+0x2c/0x90
[ 48.922001] el1h_64_sync_handler+0xcc/0xe8
[ 48.922061] el1h_64_sync+0x64/0x68
[ 48.922112] __rcu_irq_enter_check_tick+0x0/0x1b8
[...]
[ 48.938382] __rcu_irq_enter_check_tick+0x0/0x1b8
[ 48.938441] arm64_enter_el1_dbg.isra.0+0x14/0x20
[ 48.938500] el1_dbg+0x2c/0x90
[ 48.938549] el1h_64_sync_handler+0xcc/0xe8
[ 48.938607] el1h_64_sync+0x64/0x68
[ 48.938656] __rcu_irq_enter_check_tick+0x0/0x1b8
[ 48.938715] arm64_enter_el1_dbg.isra.0+0x14/0x20
[ 48.938778] el1_dbg+0x2c/0x90
[ 48.938829] el1h_64_sync_handler+0xcc/0xe8
[ 48.938887] el1h_64_sync+0x64/0x68
[ 48.938936] __rcu_irq_enter_check_tick+0x0/0x1b8
[ 48.938995] arm64_enter_el1_dbg.isra.0+0x14/0x20
[ 48.939054] el1_dbg+0x2c/0x90
[ 48.939105] el1h_64_sync_handler+0xcc/0xe8
[ 48.939164] el1h_64_sync+0x64/0x68
[ 48.939215] __rcu_irq_enter_check_tick+0x0/0x1b8
[ 48.939274] el1_interrupt+0x28/0x60
[ 48.939327] el1h_64_irq_handler+0x18/0x28
[ 48.939385] el1h_64_irq+0x64/0x68
[ 48.939434] __asan_load8+0x54/0xa8
[ 48.939500] __ftrace_set_clr_event_nolock+0x6c/0x198
[ 48.939563] __ftrace_set_clr_event+0x58/0x80
[ 48.939618] system_enable_write+0x144/0x178
[ 48.939673] vfs_write+0x174/0x738
[ 48.939734] ksys_write+0xd0/0x188
[ 48.939791] __arm64_sys_write+0x4c/0x60
[ 48.939851] invoke_syscall+0x64/0x180
[ 48.939921] el0_svc_common.constprop.0+0x84/0x160
[ 48.939996] do_el0_svc+0x48/0xf8
[ 48.940062] el0_svc+0x34/0xd0
[ 48.940114] el0t_64_sync_handler+0xb8/0xc0
[ 48.940173] el0t_64_sync+0x18c/0x190
[ 48.940872] SMP: stopping secondary CPUs
[ 48.942844] Kernel Offset: 0x2d9499c00000 from 0xffff800008000000
[ 48.942938] PHYS_OFFSET: 0xffffaa9840000000
[ 48.942999] CPU features: 0x00000,00d00080,0000421b
[ 48.943387] Memory Limit: none
>
> Thoughts?
Sorry, I have no more idea :-(
>
> Thanx, Paul
>
>> [1]
>> Insufficient stack space to handle exception!
>> Insufficient stack space to handle exception!
>> [...]
>> Kernel panic - not syncing: kernel stack overflow
>> CPU: 3 PID: 34 Comm: migration/3 Not tainted
>> 6.1.0-rc5-00884-g84368d882b96 #2
>> Hardware name: linux,dummy-virt (DT)
>> Stopper: multi_cpu_stop+0x0/0x228 <- __stop_cpus.constprop.0+0xa4/0x100
>> Call trace:
>> dump_backtrace+0xf8/0x108
>> show_stack+0x20/0x48
>> dump_stack_lvl+0x68/0x84
>> dump_stack+0x1c/0x38
>> panic+0x214/0x404
>> add_taint+0x0/0xf0
>> panic_bad_stack+0x144/0x160
>> handle_bad_stack+0x38/0x58
>> __bad_stack+0x78/0x7c
>> el1h_64_sync_handler+0x4/0xe8
>> __rcu_irq_enter_check_tick+0x0/0x1b8
>> arm64_enter_el1_dbg.isra.0+0x14/0x20
>> el1_dbg+0x2c/0x90
>> el1h_64_sync_handler+0xcc/0xe8
>> el1h_64_sync+0x64/0x68
>> __rcu_irq_enter_check_tick+0x0/0x1b8
>> arm64_enter_el1_dbg.isra.0+0x14/0x20
>> el1_dbg+0x2c/0x90
>> el1h_64_sync_handler+0xcc/0xe8
>> el1h_64_sync+0x64/0x68
>> __rcu_irq_enter_check_tick+0x0/0x1b8
>> arm64_enter_el1_dbg.isra.0+0x14/0x20
>> el1_dbg+0x2c/0x90
>> el1h_64_sync_handler+0xcc/0xe8
>> el1h_64_sync+0x64/0x68
>> __rcu_irq_enter_check_tick+0x0/0x1b8
>> arm64_enter_el1_dbg.isra.0+0x14/0x20
>> el1_dbg+0x2c/0x90
>> el1h_64_sync_handler+0xcc/0xe8
>> el1h_64_sync+0x64/0x68
>> __rcu_irq_enter_check_tick+0x0/0x1b8
>> arm64_enter_el1_dbg.isra.0+0x14/0x20
>> el1_dbg+0x2c/0x90
>> el1h_64_sync_handler+0xcc/0xe8
>> el1h_64_sync+0x64/0x68
>> __rcu_irq_enter_check_tick+0x0/0x1b8
>> [...]
>>
>> Cc: stable@vger.kernel.org
>> Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
>> Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
>> ---
>> kernel/rcu/tree.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
>> index 93416afebd59..68230f02cfb7 100644
>> --- a/kernel/rcu/tree.c
>> +++ b/kernel/rcu/tree.c
>> @@ -631,7 +631,7 @@ void rcu_irq_exit_check_preempt(void)
>> * controlled environments, this function allows RCU to get what it
>> * needs without creating otherwise useless interruptions.
>> */
>> -void __rcu_irq_enter_check_tick(void)
>> +noinstr void __rcu_irq_enter_check_tick(void)
>> {
>> struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
>>
>> --
>> 2.25.1
>>
--
Best regards,
Zheng Yejian
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick()
2022-12-02 9:54 ` Zheng Yejian
@ 2022-12-02 19:24 ` Paul E. McKenney
2022-12-05 15:35 ` Frederic Weisbecker
1 sibling, 0 replies; 7+ messages in thread
From: Paul E. McKenney @ 2022-12-02 19:24 UTC (permalink / raw)
To: Zheng Yejian
Cc: frederic, quic_neeraju, josh, rostedt, mathieu.desnoyers,
jiangshanlai, joel, rcu, linux-kernel
On Fri, Dec 02, 2022 at 05:54:48PM +0800, Zheng Yejian wrote:
>
>
> On 2022/11/22 03:57, Paul E. McKenney wrote:
> > On Sat, Nov 19, 2022 at 12:00:49PM +0800, Zheng Yejian wrote:
> > > Register kprobe on __rcu_irq_enter_check_tick() can cause kernel stack
> > > overflow [1]. This issue is first found in v5.10 and can be reproduced
> > > by enabling CONFIG_NO_HZ_FULL and doing like:
> > > # cd /sys/kernel/debug/tracing/
> > > # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
> > > # echo 1 > events/kprobes/enable
> > >
> > > So __rcu_irq_enter_check_tick() should not be kprobed, mark it as noinstr.
> >
> > Good catch!
> >
> > I am inclined to queue this, but noticed that one of its callers need
> > it to be noinstr but that the others do not.
> >
> > Need noinstr:
> >
> > o enter_from_kernel_mode() -> __enter_from_kernel_mode() ->
> > rcu_irq_enter_check_tick() -> __rcu_irq_enter_check_tick()
> >
> > Doesn't need noinstr:
> >
> > o ct_nmi_enter() -> rcu_irq_enter_check_tick() ->
> > __rcu_irq_enter_check_tick(), courtesy of the call to
> > instrumentation_begin() in ct_nmi_enter() that precedes the call
> > to rcu_irq_enter_check_tick().
> >
> > o irqentry_enter() -> rcu_irq_enter_check_tick() ->
> > __rcu_irq_enter_check_tick(), courtesy of the call to
> > instrumentation_begin() in irqentry_enter() that precedes the
> > call to rcu_irq_enter_check_tick().
> >
> > Is tagging __rcu_irq_enter_check_tick() with noinstr as
> > proposed in this patch the right thing to do, or should there
> > be calls to instrumentation_begin() and instrumentation_end() in
> > enter_from_kernel_mode()? Or something else entirely?
>
> I have tried the calls to instrumentation_{begin,end}() in
> enter_from_kernel_mode(), see [1]. But this problem can still be
> reproduced, maybe more complete calltrace info [2] is needed for
> analyzing.
>
> Did I add the instrumentation_{begin,end}() in wrong place or is there other
> caller need noinstr?
It looks OK to me, but that isn't saying much.
So I must defer to people knowing more about noinstr than do I.
Thanx, Paul
> [1]
> diff --git a/arch/arm64/kernel/entry-common.c
> b/arch/arm64/kernel/entry-common.c
> index 27369fa1c032..deed5a0941d3 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -49,7 +49,9 @@ static __always_inline void
> __enter_from_kernel_mode(struct pt_regs *regs)
> }
>
> lockdep_hardirqs_off(CALLER_ADDR0);
> + instrumentation_begin();
> rcu_irq_enter_check_tick();
> + instrumentation_end();
> trace_hardirqs_off_finish();
> }
>
>
> [2]
> [ 48.921197] Call trace:
> [ 48.921241] dump_backtrace+0xf8/0x108
> [ 48.921358] show_stack+0x20/0x48
> [ 48.921418] dump_stack_lvl+0x68/0x84
> [ 48.921477] dump_stack+0x1c/0x38
> [ 48.921530] panic+0x214/0x404
> [ 48.921598] add_taint+0x0/0xf0
> [ 48.921657] panic_bad_stack+0x144/0x160
> [ 48.921715] handle_bad_stack+0x38/0x58
> [ 48.921774] __bad_stack+0x78/0x7c
> [ 48.921825] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.921886] arm64_enter_el1_dbg.isra.0+0x14/0x20
> [ 48.921949] el1_dbg+0x2c/0x90
> [ 48.922001] el1h_64_sync_handler+0xcc/0xe8
> [ 48.922061] el1h_64_sync+0x64/0x68
> [ 48.922112] __rcu_irq_enter_check_tick+0x0/0x1b8
> [...]
> [ 48.938382] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.938441] arm64_enter_el1_dbg.isra.0+0x14/0x20
> [ 48.938500] el1_dbg+0x2c/0x90
> [ 48.938549] el1h_64_sync_handler+0xcc/0xe8
> [ 48.938607] el1h_64_sync+0x64/0x68
> [ 48.938656] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.938715] arm64_enter_el1_dbg.isra.0+0x14/0x20
> [ 48.938778] el1_dbg+0x2c/0x90
> [ 48.938829] el1h_64_sync_handler+0xcc/0xe8
> [ 48.938887] el1h_64_sync+0x64/0x68
> [ 48.938936] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.938995] arm64_enter_el1_dbg.isra.0+0x14/0x20
> [ 48.939054] el1_dbg+0x2c/0x90
> [ 48.939105] el1h_64_sync_handler+0xcc/0xe8
> [ 48.939164] el1h_64_sync+0x64/0x68
> [ 48.939215] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.939274] el1_interrupt+0x28/0x60
> [ 48.939327] el1h_64_irq_handler+0x18/0x28
> [ 48.939385] el1h_64_irq+0x64/0x68
> [ 48.939434] __asan_load8+0x54/0xa8
> [ 48.939500] __ftrace_set_clr_event_nolock+0x6c/0x198
> [ 48.939563] __ftrace_set_clr_event+0x58/0x80
> [ 48.939618] system_enable_write+0x144/0x178
> [ 48.939673] vfs_write+0x174/0x738
> [ 48.939734] ksys_write+0xd0/0x188
> [ 48.939791] __arm64_sys_write+0x4c/0x60
> [ 48.939851] invoke_syscall+0x64/0x180
> [ 48.939921] el0_svc_common.constprop.0+0x84/0x160
> [ 48.939996] do_el0_svc+0x48/0xf8
> [ 48.940062] el0_svc+0x34/0xd0
> [ 48.940114] el0t_64_sync_handler+0xb8/0xc0
> [ 48.940173] el0t_64_sync+0x18c/0x190
> [ 48.940872] SMP: stopping secondary CPUs
> [ 48.942844] Kernel Offset: 0x2d9499c00000 from 0xffff800008000000
> [ 48.942938] PHYS_OFFSET: 0xffffaa9840000000
> [ 48.942999] CPU features: 0x00000,00d00080,0000421b
> [ 48.943387] Memory Limit: none
>
>
> >
> > Thoughts?
>
> Sorry, I have no more idea :-(
>
> >
> > Thanx, Paul
> >
> > > [1]
> > > Insufficient stack space to handle exception!
> > > Insufficient stack space to handle exception!
> > > [...]
> > > Kernel panic - not syncing: kernel stack overflow
> > > CPU: 3 PID: 34 Comm: migration/3 Not tainted
> > > 6.1.0-rc5-00884-g84368d882b96 #2
> > > Hardware name: linux,dummy-virt (DT)
> > > Stopper: multi_cpu_stop+0x0/0x228 <- __stop_cpus.constprop.0+0xa4/0x100
> > > Call trace:
> > > dump_backtrace+0xf8/0x108
> > > show_stack+0x20/0x48
> > > dump_stack_lvl+0x68/0x84
> > > dump_stack+0x1c/0x38
> > > panic+0x214/0x404
> > > add_taint+0x0/0xf0
> > > panic_bad_stack+0x144/0x160
> > > handle_bad_stack+0x38/0x58
> > > __bad_stack+0x78/0x7c
> > > el1h_64_sync_handler+0x4/0xe8
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > [...]
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
> > > Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
> > > ---
> > > kernel/rcu/tree.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index 93416afebd59..68230f02cfb7 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -631,7 +631,7 @@ void rcu_irq_exit_check_preempt(void)
> > > * controlled environments, this function allows RCU to get what it
> > > * needs without creating otherwise useless interruptions.
> > > */
> > > -void __rcu_irq_enter_check_tick(void)
> > > +noinstr void __rcu_irq_enter_check_tick(void)
> > > {
> > > struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
> > > --
> > > 2.25.1
> > >
> --
> Best regards,
> Zheng Yejian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick()
2022-11-21 19:57 ` Paul E. McKenney
2022-12-02 9:54 ` Zheng Yejian
@ 2022-12-05 13:23 ` Frederic Weisbecker
2022-12-29 12:27 ` Zheng Yejian
1 sibling, 1 reply; 7+ messages in thread
From: Frederic Weisbecker @ 2022-12-05 13:23 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Zheng Yejian, quic_neeraju, josh, rostedt, mathieu.desnoyers,
jiangshanlai, joel, rcu, linux-kernel
On Mon, Nov 21, 2022 at 11:57:03AM -0800, Paul E. McKenney wrote:
> On Sat, Nov 19, 2022 at 12:00:49PM +0800, Zheng Yejian wrote:
> > Register kprobe on __rcu_irq_enter_check_tick() can cause kernel stack
> > overflow [1]. This issue is first found in v5.10 and can be reproduced
> > by enabling CONFIG_NO_HZ_FULL and doing like:
> > # cd /sys/kernel/debug/tracing/
> > # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
> > # echo 1 > events/kprobes/enable
> >
> > So __rcu_irq_enter_check_tick() should not be kprobed, mark it as noinstr.
>
> Good catch!
>
> I am inclined to queue this, but noticed that one of its callers need
> it to be noinstr but that the others do not.
>
> Need noinstr:
>
> o enter_from_kernel_mode() -> __enter_from_kernel_mode() ->
> rcu_irq_enter_check_tick() -> __rcu_irq_enter_check_tick()
>
> Doesn't need noinstr:
>
> o ct_nmi_enter() -> rcu_irq_enter_check_tick() ->
> __rcu_irq_enter_check_tick(), courtesy of the call to
> instrumentation_begin() in ct_nmi_enter() that precedes the call
> to rcu_irq_enter_check_tick().
>
> o irqentry_enter() -> rcu_irq_enter_check_tick() ->
> __rcu_irq_enter_check_tick(), courtesy of the call to
> instrumentation_begin() in irqentry_enter() that precedes the
> call to rcu_irq_enter_check_tick().
>
> Is tagging __rcu_irq_enter_check_tick() with noinstr as
> proposed in this patch the right thing to do, or should there
> be calls to instrumentation_begin() and instrumentation_end() in
> enter_from_kernel_mode()? Or something else entirely?
Tagging as noinstr doesn't look right as there are functions in
__rcu_irq_enter_check_tick() that can be traced anyway. Also that
function has the constraint that it can't be called while RCU is idle
so it's up to the caller to call instrumentation_begin()/end().
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick()
2022-12-02 9:54 ` Zheng Yejian
2022-12-02 19:24 ` Paul E. McKenney
@ 2022-12-05 15:35 ` Frederic Weisbecker
1 sibling, 0 replies; 7+ messages in thread
From: Frederic Weisbecker @ 2022-12-05 15:35 UTC (permalink / raw)
To: Zheng Yejian
Cc: paulmck, quic_neeraju, josh, rostedt, mathieu.desnoyers,
jiangshanlai, joel, rcu, linux-kernel, Peter Zijlstra
On Fri, Dec 02, 2022 at 05:54:48PM +0800, Zheng Yejian wrote:
>
>
> On 2022/11/22 03:57, Paul E. McKenney wrote:
> > On Sat, Nov 19, 2022 at 12:00:49PM +0800, Zheng Yejian wrote:
> > > Register kprobe on __rcu_irq_enter_check_tick() can cause kernel stack
> > > overflow [1]. This issue is first found in v5.10 and can be reproduced
> > > by enabling CONFIG_NO_HZ_FULL and doing like:
> > > # cd /sys/kernel/debug/tracing/
> > > # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
> > > # echo 1 > events/kprobes/enable
> > >
> > > So __rcu_irq_enter_check_tick() should not be kprobed, mark it as noinstr.
> >
> > Good catch!
> >
> > I am inclined to queue this, but noticed that one of its callers need
> > it to be noinstr but that the others do not.
> >
> > Need noinstr:
> >
> > o enter_from_kernel_mode() -> __enter_from_kernel_mode() ->
> > rcu_irq_enter_check_tick() -> __rcu_irq_enter_check_tick()
> >
> > Doesn't need noinstr:
> >
> > o ct_nmi_enter() -> rcu_irq_enter_check_tick() ->
> > __rcu_irq_enter_check_tick(), courtesy of the call to
> > instrumentation_begin() in ct_nmi_enter() that precedes the call
> > to rcu_irq_enter_check_tick().
> >
> > o irqentry_enter() -> rcu_irq_enter_check_tick() ->
> > __rcu_irq_enter_check_tick(), courtesy of the call to
> > instrumentation_begin() in irqentry_enter() that precedes the
> > call to rcu_irq_enter_check_tick().
> >
> > Is tagging __rcu_irq_enter_check_tick() with noinstr as
> > proposed in this patch the right thing to do, or should there
> > be calls to instrumentation_begin() and instrumentation_end() in
> > enter_from_kernel_mode()? Or something else entirely?
>
> I have tried the calls to instrumentation_{begin,end}() in
> enter_from_kernel_mode(), see [1]. But this problem can still be
> reproduced, maybe more complete calltrace info [2] is needed for
> analyzing.
>
> Did I add the instrumentation_{begin,end}() in wrong place or is there other
> caller need noinstr?
>
> [1]
> diff --git a/arch/arm64/kernel/entry-common.c
> b/arch/arm64/kernel/entry-common.c
> index 27369fa1c032..deed5a0941d3 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -49,7 +49,9 @@ static __always_inline void
> __enter_from_kernel_mode(struct pt_regs *regs)
> }
>
> lockdep_hardirqs_off(CALLER_ADDR0);
> + instrumentation_begin();
> rcu_irq_enter_check_tick();
> + instrumentation_end();
> trace_hardirqs_off_finish();
> }
>
>
> [2]
> [ 48.921197] Call trace:
> [ 48.921241] dump_backtrace+0xf8/0x108
> [ 48.921358] show_stack+0x20/0x48
> [ 48.921418] dump_stack_lvl+0x68/0x84
> [ 48.921477] dump_stack+0x1c/0x38
> [ 48.921530] panic+0x214/0x404
> [ 48.921598] add_taint+0x0/0xf0
> [ 48.921657] panic_bad_stack+0x144/0x160
> [ 48.921715] handle_bad_stack+0x38/0x58
> [ 48.921774] __bad_stack+0x78/0x7c
> [ 48.921825] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.921886] arm64_enter_el1_dbg.isra.0+0x14/0x20
> [ 48.921949] el1_dbg+0x2c/0x90
> [ 48.922001] el1h_64_sync_handler+0xcc/0xe8
> [ 48.922061] el1h_64_sync+0x64/0x68
> [ 48.922112] __rcu_irq_enter_check_tick+0x0/0x1b8
> [...]
> [ 48.938382] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.938441] arm64_enter_el1_dbg.isra.0+0x14/0x20
> [ 48.938500] el1_dbg+0x2c/0x90
> [ 48.938549] el1h_64_sync_handler+0xcc/0xe8
> [ 48.938607] el1h_64_sync+0x64/0x68
> [ 48.938656] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.938715] arm64_enter_el1_dbg.isra.0+0x14/0x20
> [ 48.938778] el1_dbg+0x2c/0x90
> [ 48.938829] el1h_64_sync_handler+0xcc/0xe8
> [ 48.938887] el1h_64_sync+0x64/0x68
> [ 48.938936] __rcu_irq_enter_check_tick+0x0/0x1b8
> [ 48.938995] arm64_enter_el1_dbg.isra.0+0x14/0x20
> [ 48.939054] el1_dbg+0x2c/0x90
> [ 48.939105] el1h_64_sync_handler+0xcc/0xe8
> [ 48.939164] el1h_64_sync+0x64/0x68
> [ 48.939215] __rcu_irq_enter_check_tick+0x0/0x1b8
Well, that looks strange. If that is called under instrumentation_begin()...
+Cc: Peter in case he has an idea.
Thanks.
> [ 48.939274] el1_interrupt+0x28/0x60
> [ 48.939327] el1h_64_irq_handler+0x18/0x28
> [ 48.939385] el1h_64_irq+0x64/0x68
> [ 48.939434] __asan_load8+0x54/0xa8
> [ 48.939500] __ftrace_set_clr_event_nolock+0x6c/0x198
> [ 48.939563] __ftrace_set_clr_event+0x58/0x80
> [ 48.939618] system_enable_write+0x144/0x178
> [ 48.939673] vfs_write+0x174/0x738
> [ 48.939734] ksys_write+0xd0/0x188
> [ 48.939791] __arm64_sys_write+0x4c/0x60
> [ 48.939851] invoke_syscall+0x64/0x180
> [ 48.939921] el0_svc_common.constprop.0+0x84/0x160
> [ 48.939996] do_el0_svc+0x48/0xf8
> [ 48.940062] el0_svc+0x34/0xd0
> [ 48.940114] el0t_64_sync_handler+0xb8/0xc0
> [ 48.940173] el0t_64_sync+0x18c/0x190
> [ 48.940872] SMP: stopping secondary CPUs
> [ 48.942844] Kernel Offset: 0x2d9499c00000 from 0xffff800008000000
> [ 48.942938] PHYS_OFFSET: 0xffffaa9840000000
> [ 48.942999] CPU features: 0x00000,00d00080,0000421b
> [ 48.943387] Memory Limit: none
>
>
> >
> > Thoughts?
>
> Sorry, I have no more idea :-(
>
> >
> > Thanx, Paul
> >
> > > [1]
> > > Insufficient stack space to handle exception!
> > > Insufficient stack space to handle exception!
> > > [...]
> > > Kernel panic - not syncing: kernel stack overflow
> > > CPU: 3 PID: 34 Comm: migration/3 Not tainted
> > > 6.1.0-rc5-00884-g84368d882b96 #2
> > > Hardware name: linux,dummy-virt (DT)
> > > Stopper: multi_cpu_stop+0x0/0x228 <- __stop_cpus.constprop.0+0xa4/0x100
> > > Call trace:
> > > dump_backtrace+0xf8/0x108
> > > show_stack+0x20/0x48
> > > dump_stack_lvl+0x68/0x84
> > > dump_stack+0x1c/0x38
> > > panic+0x214/0x404
> > > add_taint+0x0/0xf0
> > > panic_bad_stack+0x144/0x160
> > > handle_bad_stack+0x38/0x58
> > > __bad_stack+0x78/0x7c
> > > el1h_64_sync_handler+0x4/0xe8
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > arm64_enter_el1_dbg.isra.0+0x14/0x20
> > > el1_dbg+0x2c/0x90
> > > el1h_64_sync_handler+0xcc/0xe8
> > > el1h_64_sync+0x64/0x68
> > > __rcu_irq_enter_check_tick+0x0/0x1b8
> > > [...]
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
> > > Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
> > > ---
> > > kernel/rcu/tree.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index 93416afebd59..68230f02cfb7 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -631,7 +631,7 @@ void rcu_irq_exit_check_preempt(void)
> > > * controlled environments, this function allows RCU to get what it
> > > * needs without creating otherwise useless interruptions.
> > > */
> > > -void __rcu_irq_enter_check_tick(void)
> > > +noinstr void __rcu_irq_enter_check_tick(void)
> > > {
> > > struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
> > > --
> > > 2.25.1
> > >
> --
> Best regards,
> Zheng Yejian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick()
2022-12-05 13:23 ` Frederic Weisbecker
@ 2022-12-29 12:27 ` Zheng Yejian
0 siblings, 0 replies; 7+ messages in thread
From: Zheng Yejian @ 2022-12-29 12:27 UTC (permalink / raw)
To: frederic
Cc: jiangshanlai, joel, josh, linux-kernel, mathieu.desnoyers,
paulmck, quic_neeraju, rcu, rostedt, zhengyejian1, mhiramat
On Mon, 5 Dec 2022 14:23:53 +0100, Frederic Weisbecker wrote:
> On Mon, Nov 21, 2022 at 11:57:03AM -0800, Paul E. McKenney wrote:
> > On Sat, Nov 19, 2022 at 12:00:49PM +0800, Zheng Yejian wrote:
> > > Register kprobe on __rcu_irq_enter_check_tick() can cause kernel stack
> > > overflow [1]. This issue is first found in v5.10 and can be reproduced
> > > by enabling CONFIG_NO_HZ_FULL and doing like:
> > > # cd /sys/kernel/debug/tracing/
> > > # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
> > > # echo 1 > events/kprobes/enable
> > >
> > > So __rcu_irq_enter_check_tick() should not be kprobed, mark it as noinstr.
> >
> > Good catch!
> >
> > I am inclined to queue this, but noticed that one of its callers need
> > it to be noinstr but that the others do not.
> >
> > Need noinstr:
> >
> > o enter_from_kernel_mode() -> __enter_from_kernel_mode() ->
> > rcu_irq_enter_check_tick() -> __rcu_irq_enter_check_tick()
> >
> > Doesn't need noinstr:
> >
> > o ct_nmi_enter() -> rcu_irq_enter_check_tick() ->
> > __rcu_irq_enter_check_tick(), courtesy of the call to
> > instrumentation_begin() in ct_nmi_enter() that precedes the call
> > to rcu_irq_enter_check_tick().
> >
> > o irqentry_enter() -> rcu_irq_enter_check_tick() ->
> > __rcu_irq_enter_check_tick(), courtesy of the call to
> > instrumentation_begin() in irqentry_enter() that precedes the
> > call to rcu_irq_enter_check_tick().
> >
> > Is tagging __rcu_irq_enter_check_tick() with noinstr as
> > proposed in this patch the right thing to do, or should there
> > be calls to instrumentation_begin() and instrumentation_end() in
> > enter_from_kernel_mode()? Or something else entirely?
>
> Tagging as noinstr doesn't look right as there are functions in
> __rcu_irq_enter_check_tick() that can be traced anyway. Also that
> function has the constraint that it can't be called while RCU is idle
> so it's up to the caller to call instrumentation_begin()/end().
This problem is due to __rcu_irq_enter_check_tick() being kprobe-ed, so
how about adding __rcu_irq_enter_check_tick() into kprobe blacklist by
tagging with NOKPROBE_SYMBOL:
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index cf34a961821a..41606d3ed083 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -659,6 +659,7 @@ void __rcu_irq_enter_check_tick(void)
}
raw_spin_unlock_rcu_node(rdp->mynode);
}
+NOKPROBE_SYMBOL(__rcu_irq_enter_check_tick);
#endif /* CONFIG_NO_HZ_FULL */
+Cc: <mhiramat@kernel.org>
--
Best regards,
Zheng Yejian
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-12-29 12:26 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-19 4:00 [PATCH] rcu: Fix kernel stack overflow caused by kprobe on rcu_irq_enter_check_tick() Zheng Yejian
2022-11-21 19:57 ` Paul E. McKenney
2022-12-02 9:54 ` Zheng Yejian
2022-12-02 19:24 ` Paul E. McKenney
2022-12-05 15:35 ` Frederic Weisbecker
2022-12-05 13:23 ` Frederic Weisbecker
2022-12-29 12:27 ` Zheng Yejian
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox