netdev - Re: Query about the impact of using CONFIG_PREEMPT_RT on locking mechanisms within networking drivers

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251015110809.324e980e@gandalf.local.home>
Date: Wed, 15 Oct 2025 11:08:09 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Fabrizio Castro <fabrizio.castro.jz@...esas.com>
Cc: "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
 <edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
 "pabeni@...hat.com" <pabeni@...hat.com>, "andrew@...n.ch" <andrew@...n.ch>,
 "bigeasy@...utronix.de" <bigeasy@...utronix.de>, "clrkwllms@...nel.org"
 <clrkwllms@...nel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "linux-rt-devel@...ts.linux.dev" <linux-rt-devel@...ts.linux.dev>
Subject: Re: Query about the impact of using CONFIG_PREEMPT_RT on locking
 mechanisms within networking drivers

On Wed, 15 Oct 2025 11:24:35 +0000
Fabrizio Castro <fabrizio.castro.jz@...esas.com> wrote:

> Dear All,
> 
> We have recently started debugging some issues that only show up
> with the kernel built with CONFIG_PREEMPT_RT=y, and we have noticed
> some differences w.r.t. the non-RT version.
> 
> One of the major differences that we have noticed is that spin locks
> basically become rtmutexes with the RT kernel, whereas they are mapped
> to raw spin locks in non-RT kernels.
> 
> When is using raw spin locks directly in networking drivers considered
> acceptable (if ever)?
> 
> Thank you for taking the time for reading this email, comments welcome.

The reason for the spin locks conversion to mutexes is simply to allow for
more preemption. A raw spin lock can not be preempted. If a lock is held
for more than a microsecond, you can consider it too long. There's a few
places that may hold locks longer (like the scheduler) but there's no
choice.

To allow spin locks to become mutexes, interrupts are also converted into
threads (including softirqs). There are also "local locks" that are used
for places that need to protect per-cpu data that is usually protected by
preempt_disable().

What issues are you having? It's likely that it can be tweaked so that you
do not have issues with PREEMPT_RT.

-- Steve