Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp501045pxu; Thu, 3 Dec 2020 05:55:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJxpL1TuIGUrcyCifVt7C5RRHO5EMLHdkuF8goStE0OdAMw7PHNWb/7Ca6wjgmG1ibON/OJG X-Received: by 2002:a17:906:851:: with SMTP id f17mr2658774ejd.392.1607003759619; Thu, 03 Dec 2020 05:55:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607003759; cv=none; d=google.com; s=arc-20160816; b=Pe6qJKzxHIZzQLsyC/gxJ1Gq5fETJpkDhOJS0WV3b0nMOZ1lcYRs8J1/ro3VHJJtzQ ljek1d6ZGsHSgkRQRhZPYM7Dd0yfZBjn4IXiFfqeM37sRMzQwh9zNzkAB1Smsc91B1VS sj4uthdE4ZJd8LtQYGf2CnKb9MCGyGZ+dICwasWxqI+hn9sSK7M3PXxDFxIki1Jr/8vk JrA+wJxuhlOXuCeTkDT25zEhr0PNRMS7iUIbxJob6uLCHdFPg5bWueguxNEq1v9TrBri BaiZ3YCJL9E5Y90gm+1em0MGvJaA4KFZIDjIViDU9YPKeiVqiZPgl2NIfEDhf6l5BisS ckyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=t0p7hOAYBrhKNZxI4FRtNOpLvbhOu4qZ+Hwcyd6MULg=; b=BLIow+y9N6I+amQJH8eXCR3owoSWMVw0uZNv4TeGRvki5BizUmSA62i4Ncw5xB1dW8 HtsUeqZisIQYE1gn10LaSOqZcgcZHeoVfY8TRlUWZfESIOsKL84jx1c0EGc/HCD16YOY qlb4ECpgvgi/7xl+1rNlfAjmbteqboPO1HwWUTmqfUbocUUAf4A6pstGizNpDOOtJkql k/ldc77/ychys2PRhxf25MoiRHFZ7o4wJxu08Ny3Dt67Za9RtpTcu4oyHtW/ugYmWlN7 b4gUEOaqj3fqairaKWYT3buqIofABR7LESbg8uP3HhySMNyvuFYKLhXacrMBj4vqfwgP VcYA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gy15si1135970ejb.752.2020.12.03.05.55.36; Thu, 03 Dec 2020 05:55:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728830AbgLCNxI (ORCPT + 99 others); Thu, 3 Dec 2020 08:53:08 -0500 Received: from mail.kernel.org ([198.145.29.99]:59512 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726111AbgLCNxI (ORCPT ); Thu, 3 Dec 2020 08:53:08 -0500 From: Jessica Yu Authentication-Results: mail.kernel.org; dkim=permerror (bad message/signature format) To: linux-kernel@vger.kernel.org, systemd-devel@lists.freedesktop.org Cc: Nicolas Morey-Chaisemartin , Franck Bui , Jessica Yu Subject: [PATCH RFC 1/1] module: delay kobject uevent until after module init call Date: Thu, 3 Dec 2020 14:51:24 +0100 Message-Id: <20201203135124.16695-2-jeyu@kernel.org> X-Mailer: git-send-email 2.16.4 In-Reply-To: <20201203135124.16695-1-jeyu@kernel.org> References: <20201203135124.16695-1-jeyu@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Apparently there has been a longstanding race between udev/systemd and the module loader. Currently, the module loader sends a uevent right after sysfs initialization, but before the module calls its init function. However, some udev rules expect that the module has initialized already upon receiving the uevent. This race has been triggered recently (see link in references) in some systemd mount unit files. For instance, the configfs module creates the /sys/kernel/config mount point in its init function, however the module loader issues the uevent before this happens. sys-kernel-config.mount expects to be able to mount /sys/kernel/config upon receipt of the module loading uevent, but if the configfs module has not called its init function yet, then this directory will not exist and the mount unit fails. A similar situation exists for sys-fs-fuse-connections.mount, as the fuse sysfs mount point is created during the fuse module's init function. If udev is faster than module initialization then the mount unit would fail in a similar fashion. To fix this race, delay the module KOBJ_ADD uevent until after the module has finished calling its init routine. References: https://github.com/systemd/systemd/issues/17586 Signed-off-by: Jessica Yu --- kernel/module.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index a40ec708f8f2..e1dd0df57244 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -1897,7 +1897,6 @@ static int mod_sysfs_init(struct module *mod) if (err) mod_kobject_put(mod); - /* delay uevent until full sysfs population */ out: return err; } @@ -1934,7 +1933,6 @@ static int mod_sysfs_setup(struct module *mod, add_sect_attrs(mod, info); add_notes_attrs(mod, info); - kobject_uevent(&mod->mkobj.kobj, KOBJ_ADD); return 0; out_unreg_modinfo_attrs: @@ -3656,6 +3654,9 @@ static noinline int do_init_module(struct module *mod) blocking_notifier_call_chain(&module_notify_list, MODULE_STATE_LIVE, mod); + /* Delay uevent until module has finished its init routine */ + kobject_uevent(&mod->mkobj.kobj, KOBJ_ADD); + /* * We need to finish all async code before the module init sequence * is done. This has potential to deadlock. For example, a newly -- 2.16.4