[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250514110750.852919-1-bigeasy@linutronix.de>
Date: Wed, 14 May 2025 13:07:48 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: linux-kernel@...r.kernel.org,
linux-rt-devel@...ts.linux.dev
Cc: tglx@...utronix.de,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: [PATCH 0/2] local_lock: Move this_cpu_ptr() notation from internal to main header
While looking at what needs extra locks for PREEMPT_RT in order to rid
of the lock in local_bh_disable() I stumbled uppon two users which need
to lock the structure but the pointer is no longer per_cpu.
Patch #1 moves this_cpu_ptr() from the internal header to the main on in
order to free the name space and have the __ prefix function to
do the same but without the this_cpu_ptr(). So
local_lock_nested_bh() -> on per-CPU memory
__local_lock_nested_bh() -> on local memory.
This change has been made to all local_lock*() functions.
Patch #2 is an example why it is needed. In a nutshell the per-CPU
memory is allocated via alloc_percpu() and then the memory is
passed to queue_work_on(). The worker then retrieves the
structure via container_of(). No more per-CPU memory.
I attached #2 as an example and would route via crypto once #1 is
accepted. The user user I identified is nf_set_pipapo which is doing
something similar. This makes two users in total.
Sebastian Andrzej Siewior (2):
local_lock: Move this_cpu_ptr() notation from internal to main header.
cryptd: Use nested-BH locking for cryptd_cpu_queue
crypto/cryptd.c | 6 ++++++
include/linux/local_lock.h | 20 +++++++++----------
include/linux/local_lock_internal.h | 30 ++++++++++++++---------------
3 files changed, 31 insertions(+), 25 deletions(-)
--
2.49.0
Powered by blists - more mailing lists