On Tue, May 16, 2023 at 7:29 PM Steven Rostedt <rostedt@xxxxxxxxxxx> 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
