linux-kernel - Can we switch the tracepoints from preempt protection to rcu_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241206120709.736f943e@gandalf.local.home>
Date: Fri, 6 Dec 2024 12:07:09 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>, linux-rt-users <linux-rt-users@...r.kernel.org>
Subject: Can we switch the tracepoints from preempt protection to
 rcu_read_lock?

Hi Mathieu,

Sebastian brought up a point at our RT Stable meeting. BPF hooks into
tracepoints and can cause long latency on RT setups.

IIRC, tracepoints themselves do not need to have preemption disabled. It's
just that some of the users of tracepoints expect preemption to be disabled.

If we fix the users of tracepoints not to expect preemption to be disabled,
then we could just switch the preempt_disable code (guard(preempt)) to
rcu_read_lock()s for the tracepoint callbacks, right?

There's a one or two places in ftrace that expect it, but I don't know
enough about perf. I don't think BPF needs preemption disabled, but just
migration disabled. I know you had some patches to work around this.

We need to get BPF working without preemption disabled for RT, I'm not sure
how much you know about what needs to be fixed.

I'm not asking for you to do this work, but can you remind me what you saw
when you created the faultable tracepoints?

Thanks,

-- Steve