[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGudoHExNovL=EqHLqV4RAd1m-a2X4nhadZ9OGyxW6AXNr-8PA@mail.gmail.com>
Date: Sat, 3 Jan 2026 13:23:30 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Eric Sandeen <sandeen@...hat.com>
Cc: linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-kernel@...r.kernel.org,
Christian Brauner <brauner@...nel.org>, David Howells <dhowells@...hat.com>, lkp@...el.com,
oe-lkp@...ts.linux.dev, Alexander Viro <aviro@...hat.com>
Subject: Re: [PATCH RFC] fs: cache-align lock_class_keys in struct file_system_type
On Tue, Dec 30, 2025 at 11:45 PM Eric Sandeen <sandeen@...hat.com> wrote:
>
> On 12/30/25 4:04 PM, Mateusz Guzik wrote:
> > Instead something depends on the old layout for correctness.
>
> If I add ->mount back to the /end/ of the structure, it boots fine again,
> so I guess nothing is expecting specific offsets within the structure
> at least.
>
That's makes it weirder.
> > By any chance is this type-punned somewhere?
>
> I don't think so...
>
> > While I can't be bothered to investigate, I *suspect* the way to catch
> > this would patch out all of the lock_class_key vars & uses and boot with
> > KMSAN (or was it KASAN?). Or whatever mechanism which can tell the
> > access is oob.
>
> Can't do KASAN or KMSAN on i386, AFAIK. :(
>
> I suppose I could try such things on x86_64 just in case something shows
> up...
>
The sanitizer suggestion was to get the kernel to just tell you where
the problem is.
However, you can still use qemu's debug facilities to figure out where
the boot hangs and take it from there. Ultimately this should be
mostly a boring investigation, even if chore-heavy.
I have not used the machinery in over a decade, so no tips from my
end. But obviously it is there. ;)
Powered by blists - more mailing lists