https://bugzilla.kernel.org/show_bug.cgi?id=212337 --- Comment #11 from Luis Chamberlain (mcgrof@xxxxxxxxxx) --- (In reply to d gilbert from comment #8) > On 2021-03-18 3:14 p.m., bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > Addressing this issue first (i.e. loading things in scsi_debug_init() ). The > bulk of the work is done in that function's final for loop. Would putting > that in its own thread started by a workqueue help? If so, then > scsi_debug_init() could complete reasonably quickly. That thread > (called sdeb_add_hosts_thr, say) might still be running when a rmmod is > attempted. How to handle that? I don't think it would given we'd still move the race elsewhere. It would be nice design though to do that in principle though. Then load can be done using new sysfs knobs. But since we want to keep backward compatibility I can't see how this can help. > >> It would be an improvement IMO, if rmmod alerted the module > >> in question when it rejects a removal attempt with "device busy". > > > > rmmod does just that when it can find that. In this case it can just > provide > > a > > refcount. > > I'm looking for some callback that scsi_debug wires up in its init function > that when called will try and stop things, or at least stop adding new > things. If try_module_get() fails the module can be in leaving state, that is, its module removal is being called. But rmmod won't bother to call the unload module system call unless the refcount is 1. So, the way to avoid doing things when the module is leaving is to check for try_module_get(). Other than that, one needs its own state machine. The races I observed however likely could not be fixed with a new state machine though, given the semantics would be the same. I can't see what other information the driver can get to prevent this race at this time. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
