Linux Trace Kernel
 help / color / mirror / Atom feed
* [paulmck-rcu:dev.2025.08.13a] [tracing]  364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
@ 2025-08-21  5:26 kernel test robot
  2025-08-29 15:07 ` Paul E. McKenney
  0 siblings, 1 reply; 7+ messages in thread
From: kernel test robot @ 2025-08-21  5:26 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: oe-lkp, lkp, linux-kernel, Mathieu Desnoyers, Steven Rostedt,
	Sebastian Andrzej Siewior, linux-trace-kernel, oliver.sang


hi, Paul,

we also noticed there is similar commit in newer branch
  dev.2025.08.14a
  dev.2025.08.19a
but we didn't finish any bisect for them so far.

if the issue is already known and fixed in newer version, please just ignore
this report. sorry if any inconvenience.

below full report FYI.


Hello,

kernel test robot noticed "WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault" on:

commit: 364ac25d46eea504eb90229d2a1f92e18c1a1eae ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git dev.2025.08.13a

in testcase: boot

config: i386-randconfig-004-20250819
compiler: clang-20
test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G

(please refer to attached dmesg/kmsg for entire log/backtrace)


+----------------------------------------------------+------------+------------+
|                                                    | c0e2a3f449 | 364ac25d46 |
+----------------------------------------------------+------------+------------+
| WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault | 0          | 12         |
| EIP:do_user_addr_fault                             | 0          | 12         |
| BUG:kernel_NULL_pointer_dereference,address        | 0          | 12         |
| Oops                                               | 0          | 12         |
| EIP:do_int80_syscall_32                            | 0          | 12         |
| Kernel_panic-not_syncing:Fatal_exception           | 0          | 12         |
+----------------------------------------------------+------------+------------+


If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202508211038.c93e8603-lkp@intel.com


[    5.974959][  T117] ------------[ cut here ]------------
[ 5.975530][ T117] WARNING: CPU: 1 PID: 117 at arch/x86/mm/fault.c:1276 do_user_addr_fault (ld-temp.o:?) 
[    5.976496][  T117] Modules linked in:
[    5.976924][  T117] CPU: 1 UID: 0 PID: 117 Comm: sh Not tainted 6.17.0-rc1-00010-g364ac25d46ee #1 NONE  7aaffa6b74f3c55be0a24cdbe6593fcd4ccf301d
[    5.978263][  T117] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 5.979306][ T117] EIP: do_user_addr_fault (ld-temp.o:?) 
[ 5.979859][ T117] Code: 15 fe ff ff 89 f9 ff 75 f0 e8 96 04 00 00 83 c4 04 e9 03 fe ff ff 89 f9 89 da ff 75 f0 e8 72 01 00 00 83 c4 04 e9 ef fd ff ff <0f> 0b 89 f9 89 da ff 75 f0 e8 fc 03 00 00 83 c4 04 e9 d9 fd ff ff
All code
========
   0:	15 fe ff ff 89       	adc    $0x89fffffe,%eax
   5:	f9                   	stc
   6:	ff 75 f0             	push   -0x10(%rbp)
   9:	e8 96 04 00 00       	call   0x4a4
   e:	83 c4 04             	add    $0x4,%esp
  11:	e9 03 fe ff ff       	jmp    0xfffffffffffffe19
  16:	89 f9                	mov    %edi,%ecx
  18:	89 da                	mov    %ebx,%edx
  1a:	ff 75 f0             	push   -0x10(%rbp)
  1d:	e8 72 01 00 00       	call   0x194
  22:	83 c4 04             	add    $0x4,%esp
  25:	e9 ef fd ff ff       	jmp    0xfffffffffffffe19
  2a:*	0f 0b                	ud2		<-- trapping instruction
  2c:	89 f9                	mov    %edi,%ecx
  2e:	89 da                	mov    %ebx,%edx
  30:	ff 75 f0             	push   -0x10(%rbp)
  33:	e8 fc 03 00 00       	call   0x434
  38:	83 c4 04             	add    $0x4,%esp
  3b:	e9 d9 fd ff ff       	jmp    0xfffffffffffffe19

Code starting with the faulting instruction
===========================================
   0:	0f 0b                	ud2
   2:	89 f9                	mov    %edi,%ecx
   4:	89 da                	mov    %ebx,%edx
   6:	ff 75 f0             	push   -0x10(%rbp)
   9:	e8 fc 03 00 00       	call   0x40a
   e:	83 c4 04             	add    $0x4,%esp
  11:	e9 d9 fd ff ff       	jmp    0xfffffffffffffdef
[    5.981783][  T117] EAX: 80000000 EBX: 00000000 ECX: 00000000 EDX: 4875de00
[    5.982461][  T117] ESI: 46bf1f14 EDI: 46bf1f14 EBP: 46bf1ef0 ESP: 46bf1ec4
[    5.983152][  T117] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010046
[    5.983885][  T117] CR0: 80050033 CR2: 00000004 CR3: 06fc8000 CR4: 00040690
[    5.984575][  T117] Call Trace:
[ 5.984911][ T117] ? exc_page_fault (ld-temp.o:?) 
[ 5.985376][ T117] ? pvclock_clocksource_read_nowd (ld-temp.o:?) 
[ 5.985971][ T117] ? handle_exception (arch/x86/entry/entry_32.S:1048) 
[ 5.986454][ T117] ? do_int80_syscall_32 (ld-temp.o:?) 
[ 5.986948][ T117] ? entry_INT80_32 (arch/x86/entry/entry_32.S:945) 
[ 5.987410][ T117] ? insn_get_code_seg_params (ld-temp.o:?) 
[ 5.987948][ T117] ? pvclock_clocksource_read_nowd (ld-temp.o:?) 
[ 5.988547][ T117] ? do_int80_syscall_32 (ld-temp.o:?) 
[ 5.989050][ T117] ? pvclock_clocksource_read_nowd (ld-temp.o:?) 
[ 5.989645][ T117] ? do_int80_syscall_32 (ld-temp.o:?) 
[ 5.990146][ T117] ? entry_INT80_32 (arch/x86/entry/entry_32.S:945) 
[ 5.990611][ T117] ? irqentry_exit (ld-temp.o:?) 
[ 5.991053][ T117] ? exc_page_fault (ld-temp.o:?) 
[ 5.991512][ T117] ? entry_INT80_32 (arch/x86/entry/entry_32.S:945) 
[    5.991915][  T117] irq event stamp: 5810
[ 5.992173][ T117] hardirqs last enabled at (5809): do_wait (ld-temp.o:?) 
[ 5.992686][ T117] hardirqs last disabled at (5810): do_int80_syscall_32 (ld-temp.o:?) 
[ 5.993245][ T117] softirqs last enabled at (5692): local_bh_enable (ld-temp.o:?) 
[ 5.993776][ T117] softirqs last disabled at (5690): local_bh_disable (ld-temp.o:?) 
[    5.994304][  T117] ---[ end trace 0000000000000000 ]---


The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250821/202508211038.c93e8603-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


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

* Re: [paulmck-rcu:dev.2025.08.13a] [tracing]  364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
  2025-08-21  5:26 [paulmck-rcu:dev.2025.08.13a] [tracing] 364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault kernel test robot
@ 2025-08-29 15:07 ` Paul E. McKenney
  2025-09-03  1:34   ` Oliver Sang
  0 siblings, 1 reply; 7+ messages in thread
From: Paul E. McKenney @ 2025-08-29 15:07 UTC (permalink / raw)
  To: kernel test robot
  Cc: oe-lkp, lkp, linux-kernel, Mathieu Desnoyers, Steven Rostedt,
	Sebastian Andrzej Siewior, linux-trace-kernel

On Thu, Aug 21, 2025 at 01:26:45PM +0800, kernel test robot wrote:
> 
> hi, Paul,
> 
> we also noticed there is similar commit in newer branch
>   dev.2025.08.14a
>   dev.2025.08.19a
> but we didn't finish any bisect for them so far.
> 
> if the issue is already known and fixed in newer version, please just ignore
> this report. sorry if any inconvenience.
> 
> below full report FYI.
> 
> 
> Hello,
> 
> kernel test robot noticed "WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault" on:
> 
> commit: 364ac25d46eea504eb90229d2a1f92e18c1a1eae ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast")
> https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git dev.2025.08.13a
> 
> in testcase: boot
> 
> config: i386-randconfig-004-20250819
> compiler: clang-20
> test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> 
> (please refer to attached dmesg/kmsg for entire log/backtrace)

Thank you for your testing efforts, and apologies for being slow!

Could you please try the diagnostic patch at the end of this email?

							Thanx, Paul

> +----------------------------------------------------+------------+------------+
> |                                                    | c0e2a3f449 | 364ac25d46 |
> +----------------------------------------------------+------------+------------+
> | WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault | 0          | 12         |
> | EIP:do_user_addr_fault                             | 0          | 12         |
> | BUG:kernel_NULL_pointer_dereference,address        | 0          | 12         |
> | Oops                                               | 0          | 12         |
> | EIP:do_int80_syscall_32                            | 0          | 12         |
> | Kernel_panic-not_syncing:Fatal_exception           | 0          | 12         |
> +----------------------------------------------------+------------+------------+
> 
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202508211038.c93e8603-lkp@intel.com
> 
> 
> [    5.974959][  T117] ------------[ cut here ]------------
> [ 5.975530][ T117] WARNING: CPU: 1 PID: 117 at arch/x86/mm/fault.c:1276 do_user_addr_fault (ld-temp.o:?) 
> [    5.976496][  T117] Modules linked in:
> [    5.976924][  T117] CPU: 1 UID: 0 PID: 117 Comm: sh Not tainted 6.17.0-rc1-00010-g364ac25d46ee #1 NONE  7aaffa6b74f3c55be0a24cdbe6593fcd4ccf301d
> [    5.978263][  T117] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> [ 5.979306][ T117] EIP: do_user_addr_fault (ld-temp.o:?) 
> [ 5.979859][ T117] Code: 15 fe ff ff 89 f9 ff 75 f0 e8 96 04 00 00 83 c4 04 e9 03 fe ff ff 89 f9 89 da ff 75 f0 e8 72 01 00 00 83 c4 04 e9 ef fd ff ff <0f> 0b 89 f9 89 da ff 75 f0 e8 fc 03 00 00 83 c4 04 e9 d9 fd ff ff
> All code
> ========
>    0:	15 fe ff ff 89       	adc    $0x89fffffe,%eax
>    5:	f9                   	stc
>    6:	ff 75 f0             	push   -0x10(%rbp)
>    9:	e8 96 04 00 00       	call   0x4a4
>    e:	83 c4 04             	add    $0x4,%esp
>   11:	e9 03 fe ff ff       	jmp    0xfffffffffffffe19
>   16:	89 f9                	mov    %edi,%ecx
>   18:	89 da                	mov    %ebx,%edx
>   1a:	ff 75 f0             	push   -0x10(%rbp)
>   1d:	e8 72 01 00 00       	call   0x194
>   22:	83 c4 04             	add    $0x4,%esp
>   25:	e9 ef fd ff ff       	jmp    0xfffffffffffffe19
>   2a:*	0f 0b                	ud2		<-- trapping instruction
>   2c:	89 f9                	mov    %edi,%ecx
>   2e:	89 da                	mov    %ebx,%edx
>   30:	ff 75 f0             	push   -0x10(%rbp)
>   33:	e8 fc 03 00 00       	call   0x434
>   38:	83 c4 04             	add    $0x4,%esp
>   3b:	e9 d9 fd ff ff       	jmp    0xfffffffffffffe19
> 
> Code starting with the faulting instruction
> ===========================================
>    0:	0f 0b                	ud2
>    2:	89 f9                	mov    %edi,%ecx
>    4:	89 da                	mov    %ebx,%edx
>    6:	ff 75 f0             	push   -0x10(%rbp)
>    9:	e8 fc 03 00 00       	call   0x40a
>    e:	83 c4 04             	add    $0x4,%esp
>   11:	e9 d9 fd ff ff       	jmp    0xfffffffffffffdef
> [    5.981783][  T117] EAX: 80000000 EBX: 00000000 ECX: 00000000 EDX: 4875de00
> [    5.982461][  T117] ESI: 46bf1f14 EDI: 46bf1f14 EBP: 46bf1ef0 ESP: 46bf1ec4
> [    5.983152][  T117] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010046
> [    5.983885][  T117] CR0: 80050033 CR2: 00000004 CR3: 06fc8000 CR4: 00040690
> [    5.984575][  T117] Call Trace:
> [ 5.984911][ T117] ? exc_page_fault (ld-temp.o:?) 
> [ 5.985376][ T117] ? pvclock_clocksource_read_nowd (ld-temp.o:?) 
> [ 5.985971][ T117] ? handle_exception (arch/x86/entry/entry_32.S:1048) 
> [ 5.986454][ T117] ? do_int80_syscall_32 (ld-temp.o:?) 
> [ 5.986948][ T117] ? entry_INT80_32 (arch/x86/entry/entry_32.S:945) 
> [ 5.987410][ T117] ? insn_get_code_seg_params (ld-temp.o:?) 
> [ 5.987948][ T117] ? pvclock_clocksource_read_nowd (ld-temp.o:?) 
> [ 5.988547][ T117] ? do_int80_syscall_32 (ld-temp.o:?) 
> [ 5.989050][ T117] ? pvclock_clocksource_read_nowd (ld-temp.o:?) 
> [ 5.989645][ T117] ? do_int80_syscall_32 (ld-temp.o:?) 
> [ 5.990146][ T117] ? entry_INT80_32 (arch/x86/entry/entry_32.S:945) 
> [ 5.990611][ T117] ? irqentry_exit (ld-temp.o:?) 
> [ 5.991053][ T117] ? exc_page_fault (ld-temp.o:?) 
> [ 5.991512][ T117] ? entry_INT80_32 (arch/x86/entry/entry_32.S:945) 
> [    5.991915][  T117] irq event stamp: 5810
> [ 5.992173][ T117] hardirqs last enabled at (5809): do_wait (ld-temp.o:?) 
> [ 5.992686][ T117] hardirqs last disabled at (5810): do_int80_syscall_32 (ld-temp.o:?) 
> [ 5.993245][ T117] softirqs last enabled at (5692): local_bh_enable (ld-temp.o:?) 
> [ 5.993776][ T117] softirqs last disabled at (5690): local_bh_disable (ld-temp.o:?) 
> [    5.994304][  T117] ---[ end trace 0000000000000000 ]---
> 
> 
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20250821/202508211038.c93e8603-lkp@intel.com
> 
> 
> 
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki


commit 2d6142ce44dca77fb173bb96850634b169277214
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Thu Aug 28 12:56:42 2025 -0700

    EXP tracing: Diagnostic for __DECLARE_TRACE() use of SRCU-fast
    
    This patch is intended to test the theory that preemption needs to be
    disabled in some portion of the tracing infrastructure extending from
    the __DECLARE_TRACE() macro to the target BPF program.
    
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index a22c1ab88560b8..c422e4c5ed51ed 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -273,7 +273,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 	static inline void __do_trace_##name(proto)			\
 	{								\
 		if (cond) {						\
-			guard(srcu_fast_notrace)(&tracepoint_srcu);	\
+			guard(preempt_notrace)();			\
 			__DO_TRACE_CALL(name, TP_ARGS(args));		\
 		}							\
 	}								\

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

* Re: [paulmck-rcu:dev.2025.08.13a] [tracing]  364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
  2025-08-29 15:07 ` Paul E. McKenney
@ 2025-09-03  1:34   ` Oliver Sang
  2025-09-03 10:31     ` Paul E. McKenney
  0 siblings, 1 reply; 7+ messages in thread
From: Oliver Sang @ 2025-09-03  1:34 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: oe-lkp, lkp, linux-kernel, Mathieu Desnoyers, Steven Rostedt,
	Sebastian Andrzej Siewior, linux-trace-kernel, oliver.sang

hi, Paul,

On Fri, Aug 29, 2025 at 08:07:41AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 21, 2025 at 01:26:45PM +0800, kernel test robot wrote:
> > 
> > hi, Paul,
> > 
> > we also noticed there is similar commit in newer branch
> >   dev.2025.08.14a
> >   dev.2025.08.19a
> > but we didn't finish any bisect for them so far.
> > 
> > if the issue is already known and fixed in newer version, please just ignore
> > this report. sorry if any inconvenience.
> > 
> > below full report FYI.
> > 
> > 
> > Hello,
> > 
> > kernel test robot noticed "WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault" on:
> > 
> > commit: 364ac25d46eea504eb90229d2a1f92e18c1a1eae ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast")
> > https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git dev.2025.08.13a
> > 
> > in testcase: boot
> > 
> > config: i386-randconfig-004-20250819
> > compiler: clang-20
> > test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> > 
> > (please refer to attached dmesg/kmsg for entire log/backtrace)
> 
> Thank you for your testing efforts, and apologies for being slow!
> 
> Could you please try the diagnostic patch at the end of this email?
> 
> 							Thanx, Paul

by applying the patch, the issue gone. but since you said this is a 'diagnostic
patch', not sure if it's a real fix. anyway:

Tested-by: kernel test robot <oliver.sang@intel.com>


[...]

> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > | Closes: https://lore.kernel.org/oe-lkp/202508211038.c93e8603-lkp@intel.com

[...]

> > The kernel config and materials to reproduce are available at:
> > https://download.01.org/0day-ci/archive/20250821/202508211038.c93e8603-lkp@intel.com
> > -- 
> > 0-DAY CI Kernel Test Service
> > https://github.com/intel/lkp-tests/wiki
> 
> 
> commit 2d6142ce44dca77fb173bb96850634b169277214
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date:   Thu Aug 28 12:56:42 2025 -0700
> 
>     EXP tracing: Diagnostic for __DECLARE_TRACE() use of SRCU-fast
>     
>     This patch is intended to test the theory that preemption needs to be
>     disabled in some portion of the tracing infrastructure extending from
>     the __DECLARE_TRACE() macro to the target BPF program.
>     
>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index a22c1ab88560b8..c422e4c5ed51ed 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -273,7 +273,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
>  	static inline void __do_trace_##name(proto)			\
>  	{								\
>  		if (cond) {						\
> -			guard(srcu_fast_notrace)(&tracepoint_srcu);	\
> +			guard(preempt_notrace)();			\
>  			__DO_TRACE_CALL(name, TP_ARGS(args));		\
>  		}							\
>  	}								\

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

* Re: [paulmck-rcu:dev.2025.08.13a] [tracing]  364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
  2025-09-03  1:34   ` Oliver Sang
@ 2025-09-03 10:31     ` Paul E. McKenney
  2025-09-03 15:31       ` Steven Rostedt
  0 siblings, 1 reply; 7+ messages in thread
From: Paul E. McKenney @ 2025-09-03 10:31 UTC (permalink / raw)
  To: Oliver Sang
  Cc: oe-lkp, lkp, linux-kernel, Mathieu Desnoyers, Steven Rostedt,
	Sebastian Andrzej Siewior, linux-trace-kernel

On Wed, Sep 03, 2025 at 09:34:38AM +0800, Oliver Sang wrote:
> hi, Paul,
> 
> On Fri, Aug 29, 2025 at 08:07:41AM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 21, 2025 at 01:26:45PM +0800, kernel test robot wrote:
> > > 
> > > hi, Paul,
> > > 
> > > we also noticed there is similar commit in newer branch
> > >   dev.2025.08.14a
> > >   dev.2025.08.19a
> > > but we didn't finish any bisect for them so far.
> > > 
> > > if the issue is already known and fixed in newer version, please just ignore
> > > this report. sorry if any inconvenience.
> > > 
> > > below full report FYI.
> > > 
> > > 
> > > Hello,
> > > 
> > > kernel test robot noticed "WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault" on:
> > > 
> > > commit: 364ac25d46eea504eb90229d2a1f92e18c1a1eae ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast")
> > > https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git dev.2025.08.13a
> > > 
> > > in testcase: boot
> > > 
> > > config: i386-randconfig-004-20250819
> > > compiler: clang-20
> > > test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> > > 
> > > (please refer to attached dmesg/kmsg for entire log/backtrace)
> > 
> > Thank you for your testing efforts, and apologies for being slow!
> > 
> > Could you please try the diagnostic patch at the end of this email?
> > 
> > 							Thanx, Paul
> 
> by applying the patch, the issue gone. but since you said this is a 'diagnostic
> patch', not sure if it's a real fix. anyway:
> 
> Tested-by: kernel test robot <oliver.sang@intel.com>

Thank you very much!  This tells me that something on the code path from
the tracepoint to the BPF program needs to have preemption disabled.
I will leave the diagnostic patch in my tree, and will be looking into
what the real fix should be.

							Thanx, Paul

> [...]
> 
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > > | Closes: https://lore.kernel.org/oe-lkp/202508211038.c93e8603-lkp@intel.com
> 
> [...]
> 
> > > The kernel config and materials to reproduce are available at:
> > > https://download.01.org/0day-ci/archive/20250821/202508211038.c93e8603-lkp@intel.com
> > > -- 
> > > 0-DAY CI Kernel Test Service
> > > https://github.com/intel/lkp-tests/wiki
> > 
> > 
> > commit 2d6142ce44dca77fb173bb96850634b169277214
> > Author: Paul E. McKenney <paulmck@kernel.org>
> > Date:   Thu Aug 28 12:56:42 2025 -0700
> > 
> >     EXP tracing: Diagnostic for __DECLARE_TRACE() use of SRCU-fast
> >     
> >     This patch is intended to test the theory that preemption needs to be
> >     disabled in some portion of the tracing infrastructure extending from
> >     the __DECLARE_TRACE() macro to the target BPF program.
> >     
> >     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > 
> > diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> > index a22c1ab88560b8..c422e4c5ed51ed 100644
> > --- a/include/linux/tracepoint.h
> > +++ b/include/linux/tracepoint.h
> > @@ -273,7 +273,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> >  	static inline void __do_trace_##name(proto)			\
> >  	{								\
> >  		if (cond) {						\
> > -			guard(srcu_fast_notrace)(&tracepoint_srcu);	\
> > +			guard(preempt_notrace)();			\
> >  			__DO_TRACE_CALL(name, TP_ARGS(args));		\
> >  		}							\
> >  	}								\

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

* Re: [paulmck-rcu:dev.2025.08.13a] [tracing]  364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
  2025-09-03 10:31     ` Paul E. McKenney
@ 2025-09-03 15:31       ` Steven Rostedt
  2025-09-05 13:43         ` Paul E. McKenney
  0 siblings, 1 reply; 7+ messages in thread
From: Steven Rostedt @ 2025-09-03 15:31 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Oliver Sang, oe-lkp, lkp, linux-kernel, Mathieu Desnoyers,
	Sebastian Andrzej Siewior, linux-trace-kernel

On Wed, 3 Sep 2025 03:31:31 -0700
"Paul E. McKenney" <paulmck@kernel.org> wrote:

> > by applying the patch, the issue gone. but since you said this is a 'diagnostic
> > patch', not sure if it's a real fix. anyway:
> > 
> > Tested-by: kernel test robot <oliver.sang@intel.com>  
> 
> Thank you very much!  This tells me that something on the code path from
> the tracepoint to the BPF program needs to have preemption disabled.
> I will leave the diagnostic patch in my tree, and will be looking into
> what the real fix should be.

Was it a BPF program that triggered this? I couldn't get that from the
backtrace. Also, is this only a x86 32bit issue?

-- Steve

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

* Re: [paulmck-rcu:dev.2025.08.13a] [tracing]  364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
  2025-09-03 15:31       ` Steven Rostedt
@ 2025-09-05 13:43         ` Paul E. McKenney
  2025-09-11 12:04           ` Paul E. McKenney
  0 siblings, 1 reply; 7+ messages in thread
From: Paul E. McKenney @ 2025-09-05 13:43 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Oliver Sang, oe-lkp, lkp, linux-kernel, Mathieu Desnoyers,
	Sebastian Andrzej Siewior, linux-trace-kernel

On Wed, Sep 03, 2025 at 11:31:12AM -0400, Steven Rostedt wrote:
> On Wed, 3 Sep 2025 03:31:31 -0700
> "Paul E. McKenney" <paulmck@kernel.org> wrote:
> 
> > > by applying the patch, the issue gone. but since you said this is a 'diagnostic
> > > patch', not sure if it's a real fix. anyway:
> > > 
> > > Tested-by: kernel test robot <oliver.sang@intel.com>  
> > 
> > Thank you very much!  This tells me that something on the code path from
> > the tracepoint to the BPF program needs to have preemption disabled.
> > I will leave the diagnostic patch in my tree, and will be looking into
> > what the real fix should be.
> 
> Was it a BPF program that triggered this? I couldn't get that from the
> backtrace. Also, is this only a x86 32bit issue?

Excellent question, now that you mention it!  Your thought is that
one of the other preemption-disablings might need to be moved?

						Thanx, Paul

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

* Re: [paulmck-rcu:dev.2025.08.13a] [tracing]  364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
  2025-09-05 13:43         ` Paul E. McKenney
@ 2025-09-11 12:04           ` Paul E. McKenney
  0 siblings, 0 replies; 7+ messages in thread
From: Paul E. McKenney @ 2025-09-11 12:04 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Oliver Sang, oe-lkp, lkp, linux-kernel, Mathieu Desnoyers,
	Sebastian Andrzej Siewior, linux-trace-kernel, yonghong.song

On Fri, Sep 05, 2025 at 06:43:34AM -0700, Paul E. McKenney wrote:
> On Wed, Sep 03, 2025 at 11:31:12AM -0400, Steven Rostedt wrote:
> > On Wed, 3 Sep 2025 03:31:31 -0700
> > "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > 
> > > > by applying the patch, the issue gone. but since you said this is a 'diagnostic
> > > > patch', not sure if it's a real fix. anyway:
> > > > 
> > > > Tested-by: kernel test robot <oliver.sang@intel.com>  
> > > 
> > > Thank you very much!  This tells me that something on the code path from
> > > the tracepoint to the BPF program needs to have preemption disabled.
> > > I will leave the diagnostic patch in my tree, and will be looking into
> > > what the real fix should be.
> > 
> > Was it a BPF program that triggered this? I couldn't get that from the
> > backtrace. Also, is this only a x86 32bit issue?
> 
> Excellent question, now that you mention it!  Your thought is that
> one of the other preemption-disablings might need to be moved?

And a quick chat with Yonghong Song (added on CC) pointed out one bug
in my conversion, namely that when BPF is invoked from a tracepoint,
it expects that BPF-program entry and exit will happen on the same CPU.
So I disabled migration, as shown in the upcated commit below.

This can result in duplicate preemption disabling on the non-BPF code
paths.  Please let me know if this is a problem, easy fix if so.

Thoughts?

							Thanx, Paul

------------------------------------------------------------------------

commit 69f96ca7b79912d58e8efddb09c45c0ee9dee6a1
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Wed Jul 16 12:34:26 2025 -0700

    tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast
    
    The current use of guard(preempt_notrace)() within __DECLARE_TRACE()
    to protect invocation of __DO_TRACE_CALL() means that BPF programs
    attached to tracepoints are non-preemptible.  This is unhelpful in
    real-time systems, whose users apparently wish to use BPF while also
    achieving low latencies.  (Who knew?)
    
    One option would be to use preemptible RCU, but this introduces
    many opportunities for infinite recursion, which many consider to
    be counterproductive, especially given the relatively small stacks
    provided by the Linux kernel.  These opportunities could be shut down
    by sufficiently energetic duplication of code, but this sort of thing
    is considered impolite in some circles.
    
    Therefore, use the shiny new SRCU-fast API, which provides somewhat faster
    readers than those of preemptible RCU, at least on my laptop, where
    task_struct access is more expensive than access to per-CPU variables.
    And SRCU fast provides way faster readers than does SRCU, courtesy of
    being able to avoid the read-side use of smp_mb().  Also, it is quite
    straightforward to create srcu_read_{,un}lock_fast_notrace() functions.
    
    While in the area, SRCU now supports early boot call_srcu().  Therefore,
    remove the checks that used to avoid such use from rcu_free_old_probes()
    before this commit was applied:
    
    e53244e2c893 ("tracepoint: Remove SRCU protection")
    
    The current commit can be thought of as an approximate revert of that
    commit, with some compensating additions of preemption disabling pointed
    out by Steven Rostedt (thank you, Steven!).  This preemption disabling
    uses guard(preempt_notrace)(), and while in the area a couple of other
    use cases were also converted to guards.
    
    However, Yonghong Song points out that BPF expects non-sleepable BPF
    programs to remain on the same CPU, which means that migration must
    be disabled whenever preemption remains enabled.  In addition, non-RT
    kernels have performance expectations on BPF that would be violated
    by allowing the BPF programs to be preempted.
    
    Therefore, continue to disable preemption in non-RT kernels, and protect
    the BPF program with both SRCU and migration disabling for RT kernels,
    and even then only if preemption is not already disabled.
    
    [ paulmck: Apply kernel test robot and Yonghong Song feedback. ]
    
    Link: https://lore.kernel.org/all/20250613152218.1924093-1-bigeasy@linutronix.de/
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: <bpf@vger.kernel.org>

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 826ce3f8e1f851..9f8b19cd303acc 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -33,6 +33,8 @@ struct trace_eval_map {
 
 #define TRACEPOINT_DEFAULT_PRIO	10
 
+extern struct srcu_struct tracepoint_srcu;
+
 extern int
 tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
 extern int
@@ -115,7 +117,10 @@ void for_each_tracepoint_in_module(struct module *mod,
 static inline void tracepoint_synchronize_unregister(void)
 {
 	synchronize_rcu_tasks_trace();
-	synchronize_rcu();
+	if (IS_ENABLED(CONFIG_PREEMPT_RT))
+		synchronize_srcu(&tracepoint_srcu);
+	else
+		synchronize_rcu();
 }
 static inline bool tracepoint_is_faultable(struct tracepoint *tp)
 {
@@ -266,23 +271,29 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 		return static_branch_unlikely(&__tracepoint_##name.key);\
 	}
 
-#define __DECLARE_TRACE(name, proto, args, cond, data_proto)		\
+#define __DECLARE_TRACE(name, proto, args, cond, data_proto)			\
 	__DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
-	static inline void __do_trace_##name(proto)			\
-	{								\
-		if (cond) {						\
-			guard(preempt_notrace)();			\
-			__DO_TRACE_CALL(name, TP_ARGS(args));		\
-		}							\
-	}								\
-	static inline void trace_##name(proto)				\
-	{								\
-		if (static_branch_unlikely(&__tracepoint_##name.key))	\
-			__do_trace_##name(args);			\
-		if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) {		\
-			WARN_ONCE(!rcu_is_watching(),			\
-				  "RCU not watching for tracepoint");	\
-		}							\
+	static inline void __do_trace_##name(proto)				\
+	{									\
+		if (cond) {							\
+			if (IS_ENABLED(CONFIG_PREEMPT_RT) && preemptible()) {	\
+				guard(srcu_fast_notrace)(&tracepoint_srcu);	\
+				guard(migrate)();				\
+				__DO_TRACE_CALL(name, TP_ARGS(args));		\
+			} else {						\
+				guard(preempt_notrace)();			\
+				__DO_TRACE_CALL(name, TP_ARGS(args));		\
+			}							\
+		}								\
+	}									\
+	static inline void trace_##name(proto)					\
+	{									\
+		if (static_branch_unlikely(&__tracepoint_##name.key))		\
+			__do_trace_##name(args);				\
+		if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) {			\
+			WARN_ONCE(!rcu_is_watching(),				\
+				  "RCU not watching for tracepoint");		\
+		}								\
 	}
 
 #define __DECLARE_TRACE_SYSCALL(name, proto, args, data_proto)		\
diff --git a/include/trace/perf.h b/include/trace/perf.h
index a1754b73a8f55b..348ad1d9b5566e 100644
--- a/include/trace/perf.h
+++ b/include/trace/perf.h
@@ -71,6 +71,7 @@ perf_trace_##call(void *__data, proto)					\
 	u64 __count __attribute__((unused));				\
 	struct task_struct *__task __attribute__((unused));		\
 									\
+	guard(preempt_notrace)();					\
 	do_perf_trace_##call(__data, args);				\
 }
 
@@ -85,9 +86,8 @@ perf_trace_##call(void *__data, proto)					\
 	struct task_struct *__task __attribute__((unused));		\
 									\
 	might_fault();							\
-	preempt_disable_notrace();					\
+	guard(preempt_notrace)();					\
 	do_perf_trace_##call(__data, args);				\
-	preempt_enable_notrace();					\
 }
 
 /*
diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
index 4f22136fd4656c..fbc07d353be6b6 100644
--- a/include/trace/trace_events.h
+++ b/include/trace/trace_events.h
@@ -436,6 +436,7 @@ __DECLARE_EVENT_CLASS(call, PARAMS(proto), PARAMS(args), PARAMS(tstruct), \
 static notrace void							\
 trace_event_raw_event_##call(void *__data, proto)			\
 {									\
+	guard(preempt_notrace)();					\
 	do_trace_event_raw_event_##call(__data, args);			\
 }
 
@@ -447,9 +448,8 @@ static notrace void							\
 trace_event_raw_event_##call(void *__data, proto)			\
 {									\
 	might_fault();							\
-	preempt_disable_notrace();					\
+	guard(preempt_notrace)();					\
 	do_trace_event_raw_event_##call(__data, args);			\
-	preempt_enable_notrace();					\
 }
 
 /*
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 62719d2941c900..21bb6779821476 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -25,6 +25,9 @@ enum tp_func_state {
 extern tracepoint_ptr_t __start___tracepoints_ptrs[];
 extern tracepoint_ptr_t __stop___tracepoints_ptrs[];
 
+DEFINE_SRCU_FAST(tracepoint_srcu);
+EXPORT_SYMBOL_GPL(tracepoint_srcu);
+
 enum tp_transition_sync {
 	TP_TRANSITION_SYNC_1_0_1,
 	TP_TRANSITION_SYNC_N_2_1,
@@ -34,6 +37,7 @@ enum tp_transition_sync {
 
 struct tp_transition_snapshot {
 	unsigned long rcu;
+	unsigned long srcu_gp;
 	bool ongoing;
 };
 
@@ -46,6 +50,7 @@ static void tp_rcu_get_state(enum tp_transition_sync sync)
 
 	/* Keep the latest get_state snapshot. */
 	snapshot->rcu = get_state_synchronize_rcu();
+	snapshot->srcu_gp = start_poll_synchronize_srcu(&tracepoint_srcu);
 	snapshot->ongoing = true;
 }
 
@@ -56,6 +61,8 @@ static void tp_rcu_cond_sync(enum tp_transition_sync sync)
 	if (!snapshot->ongoing)
 		return;
 	cond_synchronize_rcu(snapshot->rcu);
+	if (!poll_state_synchronize_srcu(&tracepoint_srcu, snapshot->srcu_gp))
+		synchronize_srcu(&tracepoint_srcu);
 	snapshot->ongoing = false;
 }
 
@@ -101,17 +108,29 @@ static inline void *allocate_probes(int count)
 	return p == NULL ? NULL : p->probes;
 }
 
-static void rcu_free_old_probes(struct rcu_head *head)
+static void srcu_free_old_probes(struct rcu_head *head)
 {
 	kfree(container_of(head, struct tp_probes, rcu));
 }
 
+static void rcu_free_old_probes(struct rcu_head *head)
+{
+	call_srcu(&tracepoint_srcu, head, srcu_free_old_probes);
+}
+
 static inline void release_probes(struct tracepoint *tp, struct tracepoint_func *old)
 {
 	if (old) {
 		struct tp_probes *tp_probes = container_of(old,
 			struct tp_probes, probes[0]);
 
+		/*
+		 * Tracepoint probes are protected by either RCU or
+		 * Tasks Trace RCU and also by SRCU.  By calling the SRCU
+		 * callback in the [Tasks Trace] RCU callback we cover
+		 * both cases. So let us chain the SRCU and [Tasks Trace]
+		 * RCU callbacks to wait for both grace periods.
+		 */
 		if (tracepoint_is_faultable(tp))
 			call_rcu_tasks_trace(&tp_probes->rcu, rcu_free_old_probes);
 		else

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

end of thread, other threads:[~2025-09-11 12:04 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-21  5:26 [paulmck-rcu:dev.2025.08.13a] [tracing] 364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault kernel test robot
2025-08-29 15:07 ` Paul E. McKenney
2025-09-03  1:34   ` Oliver Sang
2025-09-03 10:31     ` Paul E. McKenney
2025-09-03 15:31       ` Steven Rostedt
2025-09-05 13:43         ` Paul E. McKenney
2025-09-11 12:04           ` Paul E. McKenney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox