If a person has CONFIG_DEBUG_KOBJECT_RELEASE enabled, and runs a rather
questionable test suite doing a repeated modprobe followed by modprobe -r
it will eventually trigger a duplicate sysfs name warning:
[ 1427.032646] kobject: 'usbserial_generic' (00000000c91a1c2c): kobject_release, parent 00000000890627c7 (delayed 4000)
[...]
[ 1430.110659] kobject: 'usbserial_generic' (00000000a633d9a5): kobject_add_internal: parent: 'drivers', set: 'drivers'
[ 1430.110667] sysfs: cannot create duplicate filename '/bus/usb/drivers/usbserial_generic'
[ 1430.110671] CPU: 2 PID: 1102 Comm: modprobe Not tainted 5.15.38 #7
[ 1430.110678] Call Trace:
[ 1430.110685] dump_stack_lvl+0x33/0x42
[ 1430.110693] sysfs_warn_dup+0x51/0x60 <----------
[ 1430.110699] sysfs_create_dir_ns+0xb8/0xd0
For context to lkml readers, CONFIG_DEBUG_KOBJECT_RELEASE inserts a
random delay of between 2 and 5 seconds before freeing a kobject.
In the above case, the free was delayed 4s by the DEBUG option, but we tried
to reconstruct the same sysfs entry in just 3s elapsed and hence it triggered
the namespace collision warning.
I'm not convinced this warrants fixing, given the contrived nature of the
root only test, but I did at least want to get it on record, so maybe it
saves someone else some research time, given a similar report.
We could I guess, within the CONFIG_DEBUG_KOBJECT_RELEASE ifdef'd code use
kobject_rename() to add a "-zombie" suffix or something like that, but then
it might mask name space collisions people *do* want to see?
As per above it was seen with usb-serial, but I suspect any driver with a
sysfs kobject could reproduce the issue. I also didn't reproduce on the
latest kernel but I can't imagine anything has changed in this area.
Paul.
On Mon, Jun 13, 2022 at 07:02:39AM -0400, Paul Gortmaker wrote:
> If a person has CONFIG_DEBUG_KOBJECT_RELEASE enabled, and runs a rather
> questionable test suite doing a repeated modprobe followed by modprobe -r
> it will eventually trigger a duplicate sysfs name warning:
>
> [ 1427.032646] kobject: 'usbserial_generic' (00000000c91a1c2c): kobject_release, parent 00000000890627c7 (delayed 4000)
> [...]
> [ 1430.110659] kobject: 'usbserial_generic' (00000000a633d9a5): kobject_add_internal: parent: 'drivers', set: 'drivers'
> [ 1430.110667] sysfs: cannot create duplicate filename '/bus/usb/drivers/usbserial_generic'
> [ 1430.110671] CPU: 2 PID: 1102 Comm: modprobe Not tainted 5.15.38 #7
> [ 1430.110678] Call Trace:
> [ 1430.110685] dump_stack_lvl+0x33/0x42
> [ 1430.110693] sysfs_warn_dup+0x51/0x60 <----------
> [ 1430.110699] sysfs_create_dir_ns+0xb8/0xd0
>
> For context to lkml readers, CONFIG_DEBUG_KOBJECT_RELEASE inserts a
> random delay of between 2 and 5 seconds before freeing a kobject.
>
> In the above case, the free was delayed 4s by the DEBUG option, but we tried
> to reconstruct the same sysfs entry in just 3s elapsed and hence it triggered
> the namespace collision warning.
>
> I'm not convinced this warrants fixing, given the contrived nature of the
> root only test, but I did at least want to get it on record, so maybe it
> saves someone else some research time, given a similar report.
It's come up many many times in the past years, sorry you hit it again
without realizing it.
> We could I guess, within the CONFIG_DEBUG_KOBJECT_RELEASE ifdef'd code use
> kobject_rename() to add a "-zombie" suffix or something like that, but then
> it might mask name space collisions people *do* want to see?
That wouldn't work as you would have rename collisions as well.
And that warning is just that, a warning that you did something foolish
so the kernel is trying to say "don't do that". And doing a
modprobe/rmmod constantly is a huge "don't do that" hint.
> As per above it was seen with usb-serial, but I suspect any driver with a
> sysfs kobject could reproduce the issue. I also didn't reproduce on the
> latest kernel but I can't imagine anything has changed in this area.
Yes, the module handling code has changed a bit, so it might have solved
some of these things. But the root cause is still there, you are doing
something odd/broken and the kernel warned you about it :)
thanks,
greg k-h