From: Bert Karwatzki <spasswolf@web•de>
To: Mateusz Guzik <mjguzik@gmail•com>
Cc: Christian Brauner <brauner@kernel•org>,
linux-kernel@vger•kernel.org, linux-next@vger•kernel.org,
linux-rt-devel@lists•linux.dev, linux-fsdevel@vger•kernel.org,
adobriyan@gmail•com, jack@suse•cz, viro@zeniv•linux.org.uk,
Sebastian Andrzej Siewior <bigeasy@linutronix•de>,
spasswolf@web•de, Thomas Gleixner <tglx@linutronix•de>
Subject: Re: context switch within RCU read-side critical section in next-20260518+ with PREEMPT_RT
Date: Thu, 21 May 2026 11:57:35 +0200 [thread overview]
Message-ID: <120781e5109918916422a7ad6602d4be29f8fbdc.camel@web.de> (raw)
In-Reply-To: <CAGudoHHaEFbft-SmPV+yTj6uMvNYWRQNYAWDP2x_sS=BcvesqA@mail.gmail.com>
Am Donnerstag, dem 21.05.2026 um 11:25 +0200 schrieb Mateusz Guzik:
> On Thu, May 21, 2026 at 11:21 AM Bert Karwatzki <spasswolf@web•de> wrote:
> >
> > Am Donnerstag, dem 21.05.2026 um 11:09 +0200 schrieb Mateusz Guzik:
> > > On Thu, May 21, 2026 at 10:53:03AM +0200, Mateusz Guzik wrote:
> > > > Christian, can you fold this in please.
> > > >
> > > > diff --git a/fs/filesystems.c b/fs/filesystems.c
> > > > index 771fc31a69b8..8f17c0abbc95 100644
> > > > --- a/fs/filesystems.c
> > > > +++ b/fs/filesystems.c
> > > > @@ -289,6 +289,7 @@ static __cold noinline int regen_filesystems_string(void)
> > > > * Did someone beat us to it?
> > > > */
> > > > if (old && old->gen == file_systems_gen) {
> > > > + spin_unlock(&file_systems_lock);
> > > > kfree(new);
> > > > return 0;
> > > > }
> > > > @@ -297,6 +298,7 @@ static __cold noinline int regen_filesystems_string(void)
> > > > * Did the list change in the meantime?
> > > > */
> > > > if (gen != file_systems_gen) {
> > > > + spin_unlock(&file_systems_lock);
> > > > kfree(new);
> > > > goto retry;
> > > > }
> > > >
> > > >
> > >
> > > Even better, I got the above fixup + some polish listed below:
> > > - removed an extra space in newlen calculation
> > > - the WARN_ON_ONCE case needs to free 'new', not 'old'
> > > - there is no READ_ONCE anymore in filesystems_proc_show()
> > >
> > > goes into the "fs: cache the string generated by reading /proc/filesystems"
> > > commit.
> > >
> > > diff --git a/fs/filesystems.c b/fs/filesystems.c
> > > index 771fc31a69b8..712316a1e3e0 100644
> > > --- a/fs/filesystems.c
> > > +++ b/fs/filesystems.c
> > > @@ -269,7 +269,7 @@ static __cold noinline int regen_filesystems_string(void)
> > > hlist_for_each_entry_rcu(p, &file_systems, list) {
> > > if (!(p->fs_flags & FS_REQUIRES_DEV))
> > > newlen += strlen("nodev");
> > > - newlen += strlen("\t") + strlen(p->name) + strlen("\n");
> > > + newlen += strlen("\t") + strlen(p->name) + strlen("\n");
> > > }
> > > spin_unlock(&file_systems_lock);
> > >
> > > @@ -289,6 +289,7 @@ static __cold noinline int regen_filesystems_string(void)
> > > * Did someone beat us to it?
> > > */
> > > if (old && old->gen == file_systems_gen) {
> > > + spin_unlock(&file_systems_lock);
> > > kfree(new);
> > > return 0;
> > > }
> > > @@ -297,6 +298,7 @@ static __cold noinline int regen_filesystems_string(void)
> > > * Did the list change in the meantime?
> > > */
> > > if (gen != file_systems_gen) {
> > > + spin_unlock(&file_systems_lock);
> > > kfree(new);
> > > goto retry;
> > > }
> > > @@ -321,13 +323,12 @@ static __cold noinline int regen_filesystems_string(void)
> > > * generation above and messes it up.
> > > */
> > > spin_unlock(&file_systems_lock);
> > > - if (old)
> > > - kfree_rcu(old, rcu);
> > > + kfree(new);
> > > return -EINVAL;
> > > }
> > >
> > > /*
> > > - * Paired with consume fence in READ_ONCE() in filesystems_proc_show()
> > > + * Paired with consume fence in rcu_dereference() in filesystems_proc_show()
> > > */
> > > smp_store_release(&file_systems_string, new);
> > > spin_unlock(&file_systems_lock);
> > >
> >
> > So it was commit 36b3306779ea
> > ("fs: cache the string generated by reading /proc/filesystems")
> > which caused the problem. If I had finished the bisection properly instead
> > of cutting I probably would have noticed this...
> >
> > So I tested
> >
> > diff --git a/fs/filesystems.c b/fs/filesystems.c
> > index 771fc31a69b8..8f17c0abbc95 100644
> > --- a/fs/filesystems.c
> > +++ b/fs/filesystems.c
> > @@ -289,6 +289,7 @@ static __cold noinline int regen_filesystems_string(void)
> > * Did someone beat us to it?
> > */
> > if (old && old->gen == file_systems_gen) {
> > + spin_unlock(&file_systems_lock);
> > kfree(new);
> > return 0;
> > }
> > @@ -297,6 +298,7 @@ static __cold noinline int regen_filesystems_string(void)
> > * Did the list change in the meantime?
> > */
> > if (gen != file_systems_gen) {
> > + spin_unlock(&file_systems_lock);
> > kfree(new);
> > goto retry;
> > }
> >
> > with next-20260519 (no RT, no LOCKDEP) and got no crash so far (4 boots only though (next-20260619
> > crashed in 2 out of 3 boots without RT)) but I get this warning on every boot:
> >
> > [ 2.793416] [ T331] ------------[ cut here ]------------
> > [ 2.793433] [ T331] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
> > [ 2.793434] [ T331] WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x586/0x10c0, CPU#17: (udev-worker)/331
>
> Just so that we are on the same page: if you take the -next tag as is
> and revert the "fs: cache the string generated by reading
> /proc/filesystems" commit alone things work fine?
Yes this works fine:
16ff8d6e7c28 (HEAD) Revert "fs: cache the string generated by reading /proc/filesystems"
6a50ba100ace (tag: next-20260519, origin/master, origin/HEAD, master) Add linux-next specific files for 20260519
(tested only without RT as the bug seems to be easier to trigger ...)
Bert Karwatzki
next prev parent reply other threads:[~2026-05-21 9:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 22:52 context switch within RCU read-side critical section in next-20260518+ with PREEMPT_RT Bert Karwatzki
2026-05-21 8:37 ` Thomas Gleixner
2026-05-21 8:53 ` Mateusz Guzik
2026-05-21 9:08 ` Sebastian Andrzej Siewior
2026-05-21 9:17 ` Mateusz Guzik
2026-05-21 9:09 ` Mateusz Guzik
2026-05-21 9:20 ` Bert Karwatzki
2026-05-21 9:25 ` Mateusz Guzik
2026-05-21 9:57 ` Bert Karwatzki [this message]
2026-05-21 10:17 ` Thomas Gleixner
2026-05-21 10:21 ` Bert Karwatzki
2026-05-21 10:33 ` Mateusz Guzik
2026-05-21 11:50 ` Bert Karwatzki
2026-05-21 12:01 ` Mateusz Guzik
2026-05-28 17:59 ` Bert Karwatzki
2026-05-29 17:20 ` Mateusz Guzik
2026-05-21 10:05 ` Thomas Gleixner
2026-05-21 10:13 ` Bert Karwatzki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=120781e5109918916422a7ad6602d4be29f8fbdc.camel@web.de \
--to=spasswolf@web$(echo .)de \
--cc=adobriyan@gmail$(echo .)com \
--cc=bigeasy@linutronix$(echo .)de \
--cc=brauner@kernel$(echo .)org \
--cc=jack@suse$(echo .)cz \
--cc=linux-fsdevel@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=linux-rt-devel@lists$(echo .)linux.dev \
--cc=mjguzik@gmail$(echo .)com \
--cc=tglx@linutronix$(echo .)de \
--cc=viro@zeniv$(echo .)linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox