On Tue, 2026-05-05 at 11:28 +0200, Ben Hutchings wrote: > 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.
I am now able to reproduce the problem. If I patch the parport_pc
driver to fail after registering a port:
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2069,7 +2069,7 @@ static struct parport
*__parport_pc_probe_port(unsigned long int base,
if (!p)
goto out3;
- base_res = request_region(base, 3, p->name);
+ base_res = NULL; // request_region(base, 3, p->name);
if (!base_res)
goto out4;
and then load and unload the lp and parport_pc modules in a loop:
while true; do modprobe lp & modprobe parport_pc; wait; rmmod lp
parport_pc; done
this triggers a crash that looks like this (or one of those seen in the
other merge bug reports) after a few cycles.
> 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.
With the above patch I can also reproduce this on 6.12.85. So this is
not actually a recent regression.
parport_pc's probe function (and those in other port drivers) does:
1. parport_register_port()
2. Allocate resources, initialise private structure, etc.
3. parport_announce_port()
Step 3 triggers client drivers to probe the port at the end of the probe
function.
But step 1 already registers the port device, so if a client driver like
lp calls __parport_register_driver() it can already start attaching to
the device.
So I think there are dangerous race conditions here even if step 2 goes
OK. But if anything fails in step 2 (which the above patch simulates)
then the port device can be torn down while the client driver is
attaching to it, resulting in a spectacular crash.
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
