Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d0bc50e3-0e42-311b-20ed-7538bb918c5b@suse.com>
Date:   Wed, 19 Oct 2022 14:00:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: [PATCH v2 2/2] module: Merge same-name module load requests
Content-Language: en-US
To:     Luis Chamberlain <mcgrof@kernel.org>,
        Prarit Bhargava <prarit@redhat.com>
Cc:     pmladek@suse.com, linux-modules@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20220919123233.8538-1-petr.pavlu@suse.com>
 <20220919123233.8538-3-petr.pavlu@suse.com>
 <YzdR0gRNQI2BGnJ9@bombadil.infradead.org>
 <aa8d9456-b260-d999-0296-8e6ab876af7a@suse.com>
 <Y07xX2ejlg0oFoEy@bombadil.infradead.org>
From:   Petr Pavlu <petr.pavlu@suse.com>
In-Reply-To: <Y07xX2ejlg0oFoEy@bombadil.infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?akdOeEFGSUlVQVZlN0NxVkROOFp3WW1STXdQUStGRXphaVFrbXdwOG5peTJ1?=
 =?utf-8?B?UFdWdEhZdzFtV2pCN1RlMmZWZDVwVVVNcTQ4NHJRRWwyZTZWY1ppSldKSHph?=
 =?utf-8?B?dkdoVjNkbnRQdE9BQW1ZdUEzNnZraVNteXpoa3IydHU1eXpFL2lONm1mMFMy?=
 =?utf-8?B?WE03S2NnU2h0V1gzNWNpOWJXUnplVDNvZUZyNkJGRDFXUHp0ank5RTlkTWJw?=
 =?utf-8?B?Y3NxcHllakNRQndjMVh5L3JlMHBFNVJOY29ReGdzd1dlVThydTRNUGM1V2Zr?=
 =?utf-8?B?azNBNWVQVzVvWXJEOWxEV0MzWm5sdWxmbFUyYjlrbjJrSDdFZENIcW9zbG5m?=
 =?utf-8?B?NHdoR2RyTktDQkdRaEFGREN6c1hlRHdiL2Q4MHIxYXlXd3Bhb2lQdU1OSWNu?=
 =?utf-8?B?M3czeGJIaTFWY3YwdFFISzZSOExRcWtMVjVYcW56TVhqSG55MGNxTUNmeTZK?=
 =?utf-8?B?d2NYc0M1dURLNUNTTUtCalBnMGN5ZFFjeVdNa041bzJtT0R3R3FCV3FldXdj?=
 =?utf-8?B?b0tqSkU0OVBqNVNzT2M2ck1vcWV2N2Vqa0pWMTFFTUw4eTcyc2d1VUNZVENT?=
 =?utf-8?B?VjM2Ui9pY0Q1bE5GUjNLTUFRcDk5MnAyU3lnb1dJazJKWk5sV0ZGVVV3K2Jw?=
 =?utf-8?B?OVNOWFcyaXg1dlE3WFlabVBJNGZ3NUV4WU9LdEtaRnZzKzFOYUxSbjJmWnNX?=
 =?utf-8?B?L3pvRTd4QUxPczNrTmJJcW83aHlNbzRrNEp0WUw2by9mbnYrcGVCUlF4eEI5?=
 =?utf-8?B?a1paRUNORnpiS251cDJwdXIxSW9QSnp6dlM4TmxLZW9IUkduUlBpU29qMUNR?=
 =?utf-8?B?NUVUQXNFTENac3hlM3hQbUh5VkQzYmN0MFJSRWdLYjRQcXNTUUprWm8vOWpq?=
 =?utf-8?B?S1RtWEQrVlRIaGIrUDh0Rys5Wi9xR0U4QWhkeWJXODdLaWxYNXNFc2ZoTTJQ?=
 =?utf-8?B?b3FaN3VqOFVMSnZtaW1mVmFFcFpnQ3huaEdtb1FKTFlNc3FOQ3h5YjhzZGJm?=
 =?utf-8?B?ZzNqa244NUk0VUhTZjZNTC9RYlQrb1pScWV6NlVwanNZWEQ1SGRtNjV3bW9p?=
 =?utf-8?B?R2V0cGVtNW5qMi9mYlBqbUtYUG0veXUyWFhZbzR0WWh6MXJIYWUrdjRPOEFU?=
 =?utf-8?B?aFZ2ako5WlZoZUU4N0hwa2dEaXphYTh4TXRzYTRuZkpEcXNkZlhZck5CeFVr?=
 =?utf-8?B?Ny95M2xVUks1NFA1WlZEMVp1cU1Qa0ZRd3lMYWJvKzB2MGxkWW9DR0VhZk9F?=
 =?utf-8?B?Zmw2cC9NT08wTDVvWUZvYnJnVnVxS1Q3QUJ6S01UYjljRHB3Y2lFbFk3QWd6?=
 =?utf-8?B?emJIcGV1aTBsekFXZ2VBd1ZQY0ZwbkV4Q3FtdUZIdy9LTExLYVF3S0ZjRmto?=
 =?utf-8?B?d0pQVCt4eWMvNU1jaGg1NDhGYWhsT0EvQ09BVEJQZ1ovU0xQbHVqY2krcXV0?=
 =?utf-8?B?UlVuR2lwTWlSVXJKQ3lXcitCays3L2xtcjFzVVJON2dZaDdzUTZKRzcxWlV5?=
 =?utf-8?B?REtqWW9MTzh1NlFMeWJCbURFKzFFbEoyZFVUSU9OV2JyTGRDUFpwWW4wcHd6?=
 =?utf-8?B?RWM4bUp3cFhsTFVhMllpcDMxOXIyUkhlYlh0SS8yeTl2OW51MEovS241VGpL?=
 =?utf-8?B?amo5SlhhVEZMNkxOSHJXN2kwQjZieituc2NPTTVRZGF6b2pYZXhzMlMvZ2p5?=
 =?utf-8?B?K2ErbWZqT0lxNWVJOVUxeGhTSkp0M210QVZHTnNkSmRjckE1TFcrUlE1b2Qv?=
 =?utf-8?B?YitPbWVPeFZGRm13UEVDb3R5Q2lPMHhtM2NGVm5Zd0ViQWN1TmZubGwyNk9P?=
 =?utf-8?B?TkxWV2tVUEF0NU1RbHd1THVxTW51dms1ZTczLzZvaVM4SHBNd1BhSnNZOFEv?=
 =?utf-8?B?RWZWSExMb3FVK2FYdFZ5STJOWlNFSU9lbDVLckE3bkErdXFSekk3TXNUOVNZ?=
 =?utf-8?B?K2lYV3p6a2kzak5EWHJwaFZMVGJDRVUyS1h6T3Z3TTFBcUE5UWtBcEgwYm5D?=
 =?utf-8?B?QkU4bldVaVExc3l3YTQ5OW1WZ3ZCUThoK2xOamhtSVVWVDM4a1ZyRXVjejdX?=
 =?utf-8?B?TFBNUlQ1eGdYTjRnYVZpU3ZJS2FlQVRJcXdTejZJSEFML0luWDZpV1h4TGZx?=
 =?utf-8?Q?dt4gnwwHW2uxRwEcKhi8a5Grg?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3401b5ae-e156-4938-71ba-08dab1c9949e
X-MS-Exchange-CrossTenant-AuthSource: AM0PR0402MB3395.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2022 12:00:57.0988
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TNpAJHVHfkcimAAE/vi2BpaIoMSePwaSAz8JyGGt/Uiox6PfWr91EwN1uMFB5U04R/4q73oKCHy1R7HIoPfgDA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR04MB8903
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/18/22 20:33, Luis Chamberlain wrote:
> On Sat, Oct 15, 2022 at 11:27:10AM +0200, Petr Pavlu wrote:
>> The patch does address a regression observed after commit 6e6de3dee51a
>> ("kernel/module.c: Only return -EEXIST for modules that have finished
>> loading"). I guess it can have a Fixes tag added to the patch.
>>
>> I think it is hard to split this patch into parts because the implemented
>> "optimization" is the fix.
> 
> git describe --contains 6e6de3dee51a
> v5.3-rc1~38^2~6
> 
> I'm a bit torn about this situation. Reverting 6e6de3dee51a would be the
> right thing to do, but without it, it still leaves the issue reported
> by Prarit Bhargava. We need a way to resolve the issue on stable and
> then your optimizations can be applied on top.

Simpler could be to do the following:

diff --git a/kernel/module/main.c b/kernel/module/main.c
index d02d39c7174e..0302ac387e93 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2386,7 +2386,8 @@ static bool finished_loading(const char *name)
 	sched_annotate_sleep();
 	mutex_lock(&module_mutex);
 	mod = find_module_all(name, strlen(name), true);
-	ret = !mod || mod->state == MODULE_STATE_LIVE;
+	ret = !mod || mod->state == MODULE_STATE_LIVE
+		|| mod->state == MODULE_STATE_GOING;
 	mutex_unlock(&module_mutex);
 
 	return ret;
@@ -2566,7 +2567,8 @@ static int add_unformed_module(struct module *mod)
 	mutex_lock(&module_mutex);
 	old = find_module_all(mod->name, strlen(mod->name), true);
 	if (old != NULL) {
-		if (old->state != MODULE_STATE_LIVE) {
+		if (old->state == MODULE_STATE_COMING
+		    || old->state == MODULE_STATE_UNFORMED) {
 			/* Wait in case it fails to load. */
 			mutex_unlock(&module_mutex);
 			err = wait_event_interruptible(module_wq,
@@ -2575,7 +2577,7 @@ static int add_unformed_module(struct module *mod)
 				goto out_unlocked;
 			goto again;
 		}
-		err = -EEXIST;
+		err = old->state != MODULE_STATE_LIVE ? -EBUSY : -EEXIST;
 		goto out;
 	}
 	mod_update_bounds(mod);

This is an alternative approach to fix the issue that 6e6de3dee51a addressed
and it preserves the previous handling of same-module parallel loads.

It works well in practice but a problem is that this previous handling is
somewhat fragile because it requires specific timings. A second load of a same
module returns EBUSY only if it observes the first load in the going state.

The following can then happen:
* A first load of module A is requested. It passes add_unformed_module() and
  proceeds with full initialization.
* A second load of module A arrives. It proceeds up to add_unformed_module()
  where it waits on the first module to complete its initialization.
* The first load fails because its init function happens to produce an error.
  The cleanup code in do_init_module() unlinks the module from the modules
  list, frees the module and finally calls wake_up_all(&module_wq).
* The second load gets woken up. It sees that there is no module with the same
  name in the modules list and continues with its full initialization, which
  likely again fails in the init function.

This scenario can be reproduced when one prepares a sample module with
"msleep(1000); return -ENODEV;" in its init function and tries to load it
several times in parallel.

My posted patch essentially brings this handling of parallel loads back but
gained some extra bits as I wanted to prevent the described instability.

However, as mentioned previously, if we can avoid these parallel same-module
load attempts in the first place then that would be certainly the best option.

Thanks,
Petr