On Wed, Dec 04, 2024 at 10:35:45PM -0600, Eric Sandeen wrote: > but that probably has more to do with the test not realizing > /before it starts/ that the module cannot be removed and it > should not even try. Right. > Darrick fixed that with: > > [PATCH 2/2] xfs/43[4-6]: implement impatient module reloading Looks good to me. > but it's starting to feel like a bit of a complex house of cards > by now. We might need a more robust framework for determining whether > a module is removable /at all/ before we decide to wait patiently > for a thing that cannot ever happen? I think the above is a good example of knowing userspace and knowing that userspace may be doing something else and we're ok to fail. Essentially, module removal is non-deterministic due to how finicky and easy it is to bump the refcnt for arbitrary reasons which are subsystem specific. The URLs in the commit log I added provide good examples of this. It is up to each subsystem to ensure a proper quiesce makes sense to ensure userspace won't do something stupid later. If one can control the test environment to quiesce first, then it makes sense to patiently remove the module. Otherwise the optional impatient removal makes sense. Luis
