Re: context switch within RCU read-side critical section in next-20260518+ with PREEMPT_RT

[Mateusz Guzik]

On Thu, May 21, 2026 at 11:08 AM Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:
>
> On 2026-05-21 10:53:03 [+0200], Mateusz Guzik wrote:
> > them in place, but when I was rebasing on top of the RCU-ifing commit I
> > figured I'm going to do guard/scoped_guard in there as well. Later it
> > started failing as the compiler did not like goto retry out of a scoped
> > guard area and the unlocks did not come back.
>
> futex_hash_allocate() has a scoped_guard a goto to again. In case it
> helps.
>

Huh, now I slapped the following for testing purposes and it compiles:
diff --git a/fs/filesystems.c b/fs/filesystems.c
index 771fc31a69b8..d21d264672c5 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -282,7 +282,7 @@ static __cold noinline int regen_filesystems_string(void)
        new->len = newlen;
        new->string[newlen] = '\0';

-       spin_lock(&file_systems_lock);
+       scoped_guard(spinlock, &file_systems_lock) {
        old = file_systems_string;

        /*
@@ -320,7 +320,6 @@ static __cold noinline int regen_filesystems_string(void)
                 * Should never happen of course, keep this in case
someone changes string
                 * generation above and messes it up.
                 */
-               spin_unlock(&file_systems_lock);
                if (old)
                        kfree_rcu(old, rcu);
                return -EINVAL;
@@ -330,7 +329,7 @@ static __cold noinline int regen_filesystems_string(void)
         * Paired with consume fence in READ_ONCE() in filesystems_proc_show()
         */
        smp_store_release(&file_systems_string, new);
-       spin_unlock(&file_systems_lock);
+       }
        if (old)
                kfree_rcu(old, rcu);
        return 0;

curious, but ultimately does not matter. I think the current code is a
little better without the guard stuff in this particular place due to
kfree calls.