[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ea678a68-6a32-42d7-a9c7-f80261d02093@paulmck-laptop>
Date: Fri, 5 Sep 2025 06:43:34 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Oliver Sang <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev,
lkp@...el.com, linux-kernel@...r.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-trace-kernel@...r.kernel.org
Subject: Re: [paulmck-rcu:dev.2025.08.13a] [tracing] 364ac25d46:
WARNING:at_arch/x86/mm/fault.c:#do_user_addr_fault
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@...nel.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@...el.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
Powered by blists - more mailing lists