Quoting Daniel Vetter (2018-12-09 17:20:02) > Drivers might want to remove some sysfs files, which needs the same > locks and ends up angering lockdep. Relevant snippet of the stack > trace: > > kernfs_remove_by_name_ns+0x3b/0x80 > bus_remove_driver+0x92/0xa0 > acpi_video_unregister+0x24/0x40 > i915_driver_unload+0x42/0x130 [i915] > i915_pci_remove+0x19/0x30 [i915] > pci_device_remove+0x36/0xb0 > device_release_driver_internal+0x185/0x250 > unbind_store+0xaf/0x180 > kernfs_fop_write+0x104/0x190 > > I've stumbled over this because some new patches by Ram connect the > snd-hda-intel unload (where we do use sysfs unbind) with the locking > chains in the i915 unload code (but without creating a new loop), > which upset our CI. But the bug is already there and can be easily > reproduced by unbind i915 directly. > > No idea whether this is the correct place to fix this, should at least > get CI happy again. > > Note that the bus locking is already done by device_release_driver -> > device_release_driver_internal, so I dropped that part. Also note that > we don't recheck that the device is still bound by the same driver, > but neither does the current code do that without races. And I figured > that's a obscure enough corner case to not bother. > > v2: Use a task work. An entirely async work leads to impressive > fireworks in our CI, notably in the vtcon bind/unbind code. Task work > will be as synchronous as the current code, and so keep all these > preexisting races neatly tugged under the rug. And maintains the ordering. Seems like either a neat trick (or horrible one depending on pov, just wait until it starts being used everywhere ;) to escape from under the dreaded kernfs_mutex. Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
