All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: linux-kernel@vger.kernel.org, systemd-devel@lists.freedesktop.org
Cc: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.com>,
	Franck Bui <fbui@suse.com>
Subject: Re: [PATCH RFC 1/1] module: delay kobject uevent until after module init call
Date: Thu, 10 Dec 2020 13:39:00 +0100	[thread overview]
Message-ID: <20201210123900.GA28117@linux-8ccs> (raw)
In-Reply-To: <20201203135124.16695-2-jeyu@kernel.org>

+++ Jessica Yu [03/12/20 14:51 +0100]:
>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 <jeyu@kernel.org>

Thanks all, this has been applied to modules-next to try to get as
much -next time as possible before the upcoming merge window.

Jessica


      parent reply	other threads:[~2020-12-10 12:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 13:51 [PATCH RFC 0/1] Delay module uevent until after initialization Jessica Yu
2020-12-03 13:51 ` [PATCH RFC 1/1] module: delay kobject uevent until after module init call Jessica Yu
2020-12-03 14:42   ` Nicolas Morey-Chaisemartin
2020-12-03 18:32   ` [systemd-devel] " Greg KH
2020-12-10 12:39   ` Jessica Yu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201210123900.GA28117@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=fbui@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nmoreychaisemartin@suse.com \
    --cc=systemd-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.