Re: [PATCH v2] module: Don't wait for GOING modules

[Petr Pavlu <petr.pavlu@suse.com>]

On 12/13/22 11:17, Petr Mladek wrote:
> On Mon 2022-12-12 21:09:19, Luis Chamberlain wrote:
>> 3) *Fixing* a kernel regression by adding new expected API for testing
>> against -EBUSY seems not ideal.
> 
> IMHO, the right solution is to fix the subsystems so that they send
> only one uevent.
> 
> The question is how the module loader would deal with "broken"
> subsystems. Petr Pavlu, please, fixme. I think that there are
> more subsystems doing this ugly thing.

The issue has been seen with cpufreq and edac modules. It is a combination of
them being loaded per CPU and use of a cooperative pattern to allow only one
module of each such type on the system.

Fixing the module loader addresses the immediate regression, but should be
useful in general to cope better if some module which is tried to be loaded
multiple times per N devices is failing its initialization.

I'm not sure if these subsystems can be called "broken". However, I agree it
makes sense to have a look at some of the mentioned drivers separately if they
can be improved to try to load them only once on each system, because they can
be viewed more as whole-platform drivers than per-CPU ones.

Thanks,
Petr