Re: [PATCH] tracing/user_events: Run BPF program if attached

On Tue, May 16, 2023 at 7:29 PM Steven Rostedt [off-list ref] wrote:

So this code path is very much in user context (called directly by a
write system call). The issue that Alexei had was that it's also in an
rcu_read_lock() section.

I wonder if this all goes away if we switch to SRCU?

Yes, SRCU context would work.

That said, how critical is this code? Because honestly, the *sanest*
thing to do is to just hold the lock that actually protects the list,
not try to walk the list in any RCU mode.

And as far as I can tell, that's the 'event_mutex', which is already held.

RCU walking of a list is only meaningful when the walk doesn't need
the lock that guarantees the list integrity.

But *modification* of a RCU-protected list still requires locking, and
from a very cursory look, it really looks like 'event_mutex' is
already the lock that protects the list.

So the whole use of RCU during the list walking there in
user_event_enabler_update() _seems_ pointless. You hold event_mutex -
user_event_enabler_write() that is called in the loop already has a
lockdep assert to that effect.

So what is it that could even race and change the list that is the
cause of that rcu-ness?

Other code in that file happily just does

        mutex_lock(&event_mutex);

        list_for_each_entry_safe(enabler, next, &mm->enablers, link)

with no RCU anywhere. Why does user_event_enabler_update() not do that?

Oh, and even those other loops are a bit strange. Why do they use the
"_safe" variant, even when they just traverse the list without
changing it? Look at user_event_enabler_exists(), for example.

I must really be missing something. That code is confusing. Or I am
very confused.

            Linus