On Mon, Jul 14, 2025 at 10:21:40AM -0400, Steven Rostedt wrote:
> On Mon, 14 Jul 2025 15:56:38 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> > 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
