Re: [PATCH RFC] fs: cache-align lock_class_keys in struct file_system_type
Mateusz Guzik <[email protected]>
| Newsgroups | dev.linux.lists.oe-lkp,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAGudoHExNovL=EqHLqV4RAd1m-a2X4nhadZ9OGyxW6AXNr-8PA@mail.gmail.com> |
On Tue, Dec 30, 2025 at 11:45 PM Eric Sandeen <[email protected]> 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. ;)