On Thu, Dec 30, 2021 at 09:08:21PM -0500, Douglas Gilbert wrote: > This patch was developed several months ago after discussions with > Luis Chamberlain. It may have been overtaken by more recent work > by Luis. Yeah well pretty much I ended up concluding that even though the driver *can* be sloppy ultimately we expose tons of knobs through userspace to easily bump module refcounts at userpace's whim's. For instance a userspace loop issuing open() on any block driver will bump the module refcnt. A simple reproducer is provided through korg#214015 [0], see busy-open-block-device-sleep.c, you run that while running the test script. In short userspace's simple open() triggers blkdev_open() and that bumps the module refcnt. This means the module refcnt is finicky. In so far as a fix is concerned, you have to consider that long ago this race was considered theoretical, and we had in-kernel support to wait to get the refcnt to 0 before unloading a module. That code proved complex, and since the race was theoretical it was removed. The race is clearly possible with any block driver, and therefore any type of driver too, and so the fix really is to implement a proper patient module remover in userspace. I already implemented and posted patches for kmod for this, they are in review. In the meantime we have needed to also open code solutions for fstests and blktest while kmod is not released yet with the new changes. I already posted patches for both, and fstests has this fix merged a while ago. Blktests folks just need to finish testing things and merge the changes. All that said, drivers can certainly be enhanced to reduce these sorts of races too. It is all driver specific and so outside of the scope of generic drivers. [0] https://bugzilla.kernel.org/show_bug.cgi?id=214015 Luis
