On Wed, 11 Mar 2026 19:30:21 +0100 jake <[email protected]> wrote: [...] > [ 20.854801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 20.854803] CR2: 000056333b377018 CR3: 0000000111f7e003 CR4: > 0000000000f70ef0 > [ 20.854806] PKRU: 55555554 > [ 20.854807] Call Trace: > [ 20.854810] <TASK> > [ 20.854814] kernfs_create_dir_ns+0x2f/0xa0
Although we are missing the top of this crash message, the following BUG
shows only a W taint flag. So we know that this was a WARN message, not
a BUG.
We don't have the RIP for the WARN, but the return address here
indicates a call to kernfs_new_node(). There is no WARN directly in
that function, but in this kernel build kernfs_get() was inlined, and
that does:
void kernfs_get(struct kernfs_node *kn)
{
if (kn) {
WARN_ON(!atomic_read(&kn->count));
atomic_inc(&kn->count);
}
}
> [ 20.854821] sysfs_create_dir_ns+0x83/0xe0
> [ 20.854826] kobject_add_internal+0xbc/0x260
> [ 20.854833] kobject_add+0x99/0xc0
> [ 20.854838] ? get_device_parent+0x23/0x1f0
> [ 20.854843] device_add+0xe1/0x880
> [ 20.854849] parport_register_dev_model+0x18c/0x340 [parport]
> [ 20.854860] lp_register+0x86/0x1b0 [lp]
[...]
So somewhere in here the reference-counting for a kernfs (i.e. sysfs)
directory has gone wrong.
These reports seem to have started appearing with 6.17, but there were
no changes in lp or parport (aside from some API renaming) between 6.12
and 6.17, so the fault may be elsewhere.
Ben.
--
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.
signature.asc
Description: This is a digitally signed message part
