Message-ID: <0ccb384f-bbd5-f0fd-3832-c2255df505b2@suse.com>
Date:   Mon, 12 Sep 2022 16:58:33 +0200
From:   Petr Pavlu <petr.pavlu@...e.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
        mwilck@...e.com, mcgrof@...nel.org
Subject: Re: [PATCH] module: Merge same-name module load requests

On 9/5/22 16:29, Petr Mladek wrote:
> On Mon 2022-09-05 10:41:31, Petr Pavlu wrote:
>> During a system boot, it can happen that the kernel receives a burst of
>> requests to insert the same module but loading it eventually fails
>> during its init call. For instance, udev can make a request to insert
>> a frequency module for each individual CPU when another frequency module
>> is already loaded which causes the init function of the new module to
>> return an error.
>>
>> The module loader currently serializes all such requests, with the
>> barrier in add_unformed_module(). This creates a lot of unnecessary work
>> and delays the boot.
> 
> Is it just an optimization or does it fix any real problem?
> It would be nice to provide some more details here.
> Otherwise, we do not know if the behavior change is worth it.

Motivation for this patch is to fix an issue observed on larger machines with
many CPUs where it can take a significant amount of time during boot to run
systemd-udev-trigger.service. An x86-64 system can have already intel_pstate
active but as its CPUs can match also acpi_cpufreq and pcc_cpufreq, udev will
attempt to load these modules too. The operation will eventually fail in the
init function of a respective module where it gets recognized that another
cpufreq driver is already loaded and -EEXIST is returned. However, one uevent
is triggered for each CPU and so multiple loads of these modules will be
present. The current code then processes all such loads individually and
serializes them with the barrier in add_unformed_module().

This can create a significant delay of several minutes. It prevents loading
drivers for other devices and might cause timeouts of services waiting on
them.

The issue was also observed with EDAC drivers which are similarly exclusive.

The problem was introduced with 6e6de3dee51a ("kernel/module.c: Only return
-EEXIST for modules that have finished loading") but arguably the previous
behavior was not well defined.

>> This patch improves the behavior as follows:
>> * A check whether a module load matches an already loaded module is
>>   moved right after a module name is determined.
>> * A new reference-counted shared_load_info structure is introduced to
>>   keep track of duplicate load requests. Two loads are considered
>>   equivalent if their module name matches. In case a load duplicates
>>   another running insert, the code waits for its completion and then
>>   returns -EEXIST or -ENODEV depending on whether it succeeded.
> 
> -ENODEV is strange, see https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html
> 
>    Macro: int ENODEV
> 
>        “No such device.” The wrong type of device was given
>        to a function that expects a particular sort of device.
> 
> IMHO, it does not fit here. What about -EBUSY?
> 
>    Macro: int EBUSY
> 
>        “Device or resource busy.” A system resource that can’t
>        be shared is already in use. For example, if you try
>        to delete a file that is the root of a currently mounted
>        filesystem, you get this error.

Ok, makes sense.

>> Note that prior to 6e6de3dee51a ("kernel/module.c: Only return -EEXIST
>> for modules that have finished loading"), the kernel already did merge
>> some of same load requests but it was more by accident and relied on
>> specific timing. The patch brings this behavior back in a more explicit
>> form.
>>
>> ---
>>  kernel/module/main.c | 207 ++++++++++++++++++++++++++++++-------------
>>  1 file changed, 144 insertions(+), 63 deletions(-)
>>
>> diff --git a/kernel/module/main.c b/kernel/module/main.c
>> index a4e4d84b6f4e..24d0777c48e3 100644
>> --- a/kernel/module/main.c
>> +++ b/kernel/module/main.c
>> @@ -2552,43 +2539,129 @@ static int may_init_module(void)
>>  	return 0;
>>  }
>>  
>> +static struct shared_load_info *
>> +shared_load_info_alloc(const struct load_info *info)
>> +{
>> +	struct shared_load_info *shared_info =
>> +		kzalloc(sizeof(*shared_info), GFP_KERNEL);
>> +	if (shared_info == NULL)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	strscpy(shared_info->name, info->name, sizeof(shared_info->name));
>> +	refcount_set(&shared_info->refcnt, 1);
>> +	INIT_LIST_HEAD(&shared_info->list);
>> +	return shared_info;
>> +}
>> +
>> +static void shared_load_info_get(struct shared_load_info *shared_info)
>> +{
>> +	refcount_inc(&shared_info->refcnt);
>> +}
>> +
>> +static void shared_load_info_put(struct shared_load_info *shared_info)
>> +{
>> +	if (refcount_dec_and_test(&shared_info->refcnt))
>> +		kfree(shared_info);
>> +}
>> +
>>  /*
>> - * We try to place it in the list now to make sure it's unique before
>> - * we dedicate too many resources.  In particular, temporary percpu
>> + * Check that the module load is unique and make it visible to others. The code
>> + * looks for parallel running inserts and already loaded modules. Two inserts
>> + * are considered equivalent if their module name matches. In case this load
>> + * duplicates another running insert, the code waits for its completion and
>> + * then returns -EEXIST or -ENODEV depending on whether it succeeded.
>> + *
>> + * Detecting early that a load is unique avoids dedicating too many cycles and
>> + * resources to bring up the module. In particular, it prevents temporary percpu
>>   * memory exhaustion.
>> + *
>> + * Merging same load requests then primarily helps during the boot process. It
>> + * can happen that the kernel receives a burst of requests to load the same
>> + * module (for example, a same module for each individual CPU) and loading it
>> + * eventually fails during its init call. Merging the requests allows that only
>> + * one full attempt to load the module is made.
>> + *
>> + * On a non-error return, it is guaranteed that this load is unique.
>>   */
>> -static int add_unformed_module(struct module *mod)
>> +static struct shared_load_info *add_running_load(const struct load_info *info)
>>  {
>> -	int err;
>>  	struct module *old;
>> +	struct shared_load_info *shared_info;
>>  
>> -	mod->state = MODULE_STATE_UNFORMED;
>> -
>> -again:
>>  	mutex_lock(&module_mutex);
>> -	old = find_module_all(mod->name, strlen(mod->name), true);
>> -	if (old != NULL) {
>> -		if (old->state != MODULE_STATE_LIVE) {
>> -			/* Wait in case it fails to load. */
>> +
>> +	/* Search if there is a running load of a module with the same name. */
>> +	list_for_each_entry(shared_info, &running_loads, list)
>> +		if (strcmp(shared_info->name, info->name) == 0) {
>> +			int err;
>> +
>> +			shared_load_info_get(shared_info);
>>  			mutex_unlock(&module_mutex);
>> +
>>  			err = wait_event_interruptible(module_wq,
>> -					       finished_loading(mod->name));
>> -			if (err)
>> -				goto out_unlocked;
>> -			goto again;
>> +						       shared_info->err != 0);
>> +			if (!err)
>> +				err = shared_info->err;
> 
> The logic around shared_info->err is a bit tricky. The value 0
> means that the parallel load is still in progress. Any error
> value means that it has finished. Where -EEXIST means that
> the load actually succeeded.
> 
> Such optimizations might make sense when they might safe a lot
> of memory. And even in these situations we should do out best
> to keep the logic straightforward.
> 
> I suggest to set shared_info->err to the really returned value.

Ok.

> And use another logic to check if the load finished. Either
> add a boolean. Or we might actually use shared_info->list.
> 
> struct shared_info is removed from @running_loads list when
> the load finished. We could do in finalize_running_load():
> 
> 	list_del_init(&shared_info->list);
> 
> and here:
> 
> 			err = wait_event_interruptible(module_wq,
> 						       list_empty(&shared_info->list);
> 
> 			/*
> 			 * Do not retry the module load when the parallel one
> 			 * failed. But do not return the exact error code
> 			 * because the parallel load might have used another
> 			 * module parameters. Instead return -EBUSY.
> 			 */
> 			if (!err) {
> 				err = shared_info->err ? -EBUSY : -EEXIST;
> [...]

Noted, discussed below.

>> +			shared_load_info_put(shared_info);
>> +			shared_info = ERR_PTR(err);
>> +			goto out_unlocked;
>>  		}
>> -		err = -EEXIST;
>> +
>> +	/* Search if there is a live module with the given name already. */
>> +	old = find_module_all(info->name, strlen(info->name), true);
>> +	if (old != NULL) {
>> +		if (old->state == MODULE_STATE_LIVE) {
>> +			shared_info = ERR_PTR(-EEXIST);
>> +			goto out;
>> +		}
>> +
>> +		/*
>> +		 * Any active load always has its record in running_loads and so
>> +		 * would be found above. This applies independent whether such
>> +		 * a module is currently in MODULE_STATE_UNFORMED,
>> +		 * MODULE_STATE_COMING, or even in MODULE_STATE_GOING if its
>> +		 * initialization failed. It therefore means this must be an
>> +		 * older going module and the caller should try later once it is
>> +		 * gone.
>> +		 */
>> +		WARN_ON(old->state != MODULE_STATE_GOING);
>> +		shared_info = ERR_PTR(-EAGAIN);
> 
> I would return -EBUSY here to avoid too many variants. The load failed because
> the same module was being loaded or unloaded.
> 
> Anyway, it should be described in the commit message.

Ack, I'll change this error to -EBUSY too.

>>  		goto out;
>>  	}
>> -	mod_update_bounds(mod);
>> -	list_add_rcu(&mod->list, &modules);
>> -	mod_tree_insert(mod);
>> -	err = 0;
>> +
>> +	/* The load is unique, make it visible to others. */
>> +	shared_info = shared_load_info_alloc(info);
>> +	if (IS_ERR(shared_info))
>> +		goto out;
>> +	list_add(&shared_info->list, &running_loads);
>>  
>>  out:
>>  	mutex_unlock(&module_mutex);
>>  out_unlocked:
>> -	return err;
>> +	return shared_info;
>> +}
>> +
>> +/* Complete the running load and inform other duplicate inserts about it. */
>> +static void finalize_running_load(struct shared_load_info *shared_info, int err)
>> +{
>> +	mutex_lock(&module_mutex);
>> +	list_del(&shared_info->list);
>> +	shared_info->err = err == 0 ? -EEXIST : -ENODEV;
> 
> As explained above, I suggest to use:
> 
> 	list_del_init(&shared_info->list);
> 	shared_info->err = err;
> 
>> +	mutex_unlock(&module_mutex);
>> +
>> +	wake_up_all(&module_wq);
> 
> Heh, this should be wake_up_interruptible() to match
> the wait_event_interruptible().
> 
> The _all() variant is used when there exclusive waiters. I have
> recently learned about it, see
> https://lore.kernel.org/all/CAHk-=wgC47n_7E6UtFx_agkJtLmWOXGsjdFjybBFYNA1AheQLQ@mail.gmail.com/
> 
> But it should be fixed in a separate patch because the same mistake
> was there even before.

I'll add a separate patch to the series to correct it.

> Also it would make sense to add the wait queue head into struct
> shared_info to reduce spurious wakeups. The head is small,
> the struct is allocated anyway, and the lifecycle is the same.

Considering this and your previous comment about waiting on shared_info->err,
it looks best to me to use a per-shared_load_info completion.

>> +	shared_load_info_put(shared_info);
>> +}
>> +
>> +static void add_unformed_module(struct module *mod)
>> +{
>> +	mod->state = MODULE_STATE_UNFORMED;
>> +
>> +	mutex_lock(&module_mutex);
>> +	mod_update_bounds(mod);
>> +	list_add_rcu(&mod->list, &modules);
>> +	mod_tree_insert(mod);
>> +	mutex_unlock(&module_mutex);
>>  }
>>  
>>  static int complete_formation(struct module *mod, struct load_info *info)
> 
> Otherwise, the patch looks good to me.

Thank you for the review. I will prepare v2 of the patch.

Petr

Powered by blists - more mailing lists