Thread (45 messages) flat view 45 messages, 5 authors, 2025-07-16

Re: [PATCH v13 09/14] unwind deferred: Use SRCU unwind_deferred_task_work()

From: Peter Zijlstra <peterz@infradead.org>
Date: 2025-07-14 15:04:02
Also in: bpf, lkml

On Mon, Jul 14, 2025 at 10:21:40AM -0400, Steven Rostedt wrote:
On Mon, 14 Jul 2025 15:56:38 +0200
Peter Zijlstra [off-list ref] wrote:
quoted
Please; something like so:
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -524,4 +524,9 @@ DEFINE_LOCK_GUARD_1(srcu, struct srcu_st
 		    srcu_read_unlock(_T->lock, _T->idx),
 		    int idx)
 
+DEFINE_LOCK_GUARD_1(srcu_lite, struct srcu_struct,
+		    _T->idx = srcu_read_lock_lite(_T->lock),
+		    srcu_read_unlock_lite(_T->lock, _T->idx),
+		    int idx)
+
 #endif
--- a/kernel/unwind/deferred.c
+++ b/kernel/unwind/deferred.c
@@ -165,7 +165,7 @@ static void unwind_deferred_task_work(st
 
 	cookie = info->id.id;
 
-	guard(mutex)(&callback_mutex);
+	guard(srcu_lite)(&unwind_srcu);
 	list_for_each_entry(work, &callbacks, list) {
 		work->func(work, &trace, cookie);
 	}
I think I rather have a scoped_guard() here. One thing that bothers me
about the guard() logic is that it could easily start to "leak"
protection. That is, the unwind_srcu is only needed for walking the
list. The reason I chose to open code the protection, is because I
wanted to distinctly denote where the end of the protection was.
Sure. But the point was more to:
 - use scru_lite; and,
 - use guards
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help