Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp4983750rwd; Tue, 30 May 2023 12:48:06 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4oUcA63b9JNmOR6SpV1fzWTJ9nWv1rUNgYIXyR50NQ855mM977wKOXfeymM1Y+AyONAZqo X-Received: by 2002:a17:902:d34b:b0:1ac:8717:d436 with SMTP id l11-20020a170902d34b00b001ac8717d436mr2954120plk.60.1685476086501; Tue, 30 May 2023 12:48:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685476086; cv=none; d=google.com; s=arc-20160816; b=gyNqW9w8px89kaLS+MLNoLcyeXpXVKipiU7MTmjWkpus7uaTXCURd9+gwf3H+N/BeU ldWmbsRLhvFQACbt4PkTKIavyspslkCFISlA4edErNy3qbkMlCjUo65f039vh/SIIYdZ NeVlzlusYWeNm4dxaT5A0IcgGsqFCf78eK1vG5BBgfBDzVP8EU3GRlPhJz88Ii1T8V79 dWi221janOIi9pTpb8VyO6rZc3aREdA2sZ4OAKpgc02X73wQdGmLEJMnDVDEuyPVpTyB ZwchkmcHjlJ6i3R7wqe2NVvwr3tXQVY4pt/E0RAUnb5IBIThlev0Li6xN9DhiyyHS4Gj 3fFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=JADWF5FGfjqal0Tm4srMFuXcLVsdz79srAuWZWBhE0U=; b=LinedLZCGwPc1Fs5xtZJaasnWQsIkubRkBLR0BL0idr0x2uVfZDb8XkpKFZ1ukw2u0 zqtFmo8UBgTf4l806iI4Bd5Q6GqEfl5Zt9eP06QUReCRvnXGs+LLAHQQMFJUfB3A6BEL KpFS/ijXz/PkPJvTfZ1LOTeAESZ0daPrk85Q9UkUmXU2Y0UkJpWCJzPIRoHL7zRM7mcF ywbx8iLPZgPFrGVEPrebreInFwLHehb6/wz2Zyv6SddoipS4i4qkv8hDl7r3uFjr/pnK NgdskYjYFAPpRZRCEXEWpWoX3MNW5MMpNK1WPuLwMARfo/zSlCZaBukQuNNneAU06mEx y87w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=h83GzI9G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u9-20020a17090341c900b001b058f1c420si1016056ple.564.2023.05.30.12.47.54; Tue, 30 May 2023 12:48:06 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=h83GzI9G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232209AbjE3Tmr (ORCPT + 99 others); Tue, 30 May 2023 15:42:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231203AbjE3Tmo (ORCPT ); Tue, 30 May 2023 15:42:44 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87D56E8; Tue, 30 May 2023 12:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=JADWF5FGfjqal0Tm4srMFuXcLVsdz79srAuWZWBhE0U=; b=h83GzI9GcktWKcxm3mM6r0dFZw gDFov6i/D/ln27TGWCDBsfM8Dp2YSXIPS/PadQ/vuOP1h3KfOXRt/Ai8fqtSLwMPPA12Cqi9fsxx1 busls/x8Bbmq5as1k5M4iPcu+jv5Y4OzfZeFCee+0guhE8+nmfE57I6/H7B7Ihh6piFFztXsoWYjP OYAhAjIj5Zrcp5vuE6HXHhK6/EWyS8a9n0RzpJbz+hN84xLsxNNYkNlVBLucSrghgbLJaaYT0asy9 fMykJWPxnNC1FQbewSoj16im5rO8ZVWciD6VuY92UqYF/2BExw7xImmCHnXCRQD1CvyE6kA4zoUJp 3FXLT1pw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1q45Dk-00F0Eb-2F; Tue, 30 May 2023 19:41:28 +0000 Date: Tue, 30 May 2023 12:41:28 -0700 From: Luis Chamberlain To: Lucas De Marchi Cc: Linus Torvalds , Johan Hovold , Petr Pavlu , gregkh@linuxfoundation.org, rafael@kernel.org, song@kernel.org, lucas.de.marchi@gmail.com, christophe.leroy@csgroup.eu, peterz@infradead.org, rppt@kernel.org, dave@stgolabs.net, willy@infradead.org, vbabka@suse.cz, mhocko@suse.com, dave.hansen@linux.intel.com, colin.i.king@gmail.com, jim.cromie@gmail.com, catalin.marinas@arm.com, jbaron@akamai.com, rick.p.edgecombe@intel.com, yujie.liu@intel.com, david@redhat.com, tglx@linutronix.de, hch@lst.de, patches@lists.linux.dev, linux-modules@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, pmladek@suse.com, prarit@redhat.com, lennart@poettering.net Subject: Re: [PATCH 2/2] module: add support to avoid duplicates early on load Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Luis Chamberlain X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED 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: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 30, 2023 at 10:16:22AM -0700, Lucas De Marchi wrote: > On Tue, May 30, 2023 at 09:22:14AM -0700, Luis Chamberlain wrote: > > Lucas, any thoughts from modules kmod userspace perspective into > > supporting anyone likely issuing concurrent modules requests with > > differing arguments? > > Changing module params like that without first explicitly removing the > module was never supported by kmod or module-init-tools (I'm not digging > the history before 2.6 kernel) That's good enough. > During boot, note there is already a shortcut > if we have the sysfs node already in the "live" state or if the module is > built-in. In that case we will return success or -EEXIST (if the > KMOD_PROBE_IGNORE_LOADED flag was passed). Linus' code would make duplicates wait and share the same return value, ie, no new odd error code is returned. Or are you suggesting -EEXIST should be returned to duplicates if the module succeeded to load instead of 0 ? > The only scenario I can think of during boot in which the module params > could change would be when a buggy initrd is created, i.e. > /etc/modprobed.d/*.conf is in the rootfs but absent from initrd. This helps thanks. > So returning the same error code seems good to me. OK thanks! So just to confirm, it seems fine to return the same error code if duplicates wait, or do you prefer for some reason for there to be an exception and return -EEXIST if the module did succeed in the duplicate case? Luis