Linux Trace Kernel
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: kernel test robot <oliver.sang@intel.com>
Cc: oe-lkp@lists.linux.dev, lkp@intel.com,
	linux-kernel@vger.kernel.org,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [paulmck-rcu:dev.2025.08.13a] [tracing]  364ac25d46: WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
Date: Fri, 29 Aug 2025 08:07:41 -0700	[thread overview]
Message-ID: <68044ea3-32c1-4d72-9bd3-fe2031669d79@paulmck-laptop> (raw)
In-Reply-To: <202508211038.c93e8603-lkp@intel.com>

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));		\
 		}							\
 	}								\

  reply	other threads:[~2025-08-29 15:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=68044ea3-32c1-4d72-9bd3-fe2031669d79@paulmck-laptop \
    --to=paulmck@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox