public inbox for linux-kernel@vger.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>, Jessica Yu <jeyu@kernel.org>
Subject: [PATCH RFC 0/1] Delay module uevent until after initialization
Date: Thu,  3 Dec 2020 14:51:23 +0100	[thread overview]
Message-ID: <20201203135124.16695-1-jeyu@kernel.org> (raw)

Hi,

This patch addresses a race condition between udev and the module loader
that was recently described here:

    https://github.com/systemd/systemd/issues/17586

Currently, the module loader issues a KOBJ_ADD uevent before it calls a
module's initialization function. Some mount units expect that the module
has initialized already upon receiving the uevent. For instance, the
configfs module creates the /sys/kernel/config mount point during its init
function, but the module loader issues the uevent before the init function
is called. If udev processes the uevent before the module loader calls the
init function, then the mount unit will fail, since /sys/kernel/config will
not exist yet.

Nicolas Morey-Chaisemartin provided a simple test script to trigger the
race condition:

while true; do
        umount configfs
        rmmod configfs
        sleep 1
        modprobe configfs
        ls -alFd /sys/kernel/config
        sleep 1
        systemctl status sys-kernel-config.mount | tail -n 1
done

When the mount fails due to the race condition, you would see a message like:

systemd[1]: Condition check resulted in Kernel Configuration File System being skipped.

I ran the script for about 30 minutes on my own machine and managed to trigger
the failure condition 4 times. With the patch applied, I was not able to
trigger the failed condition anymore after running the script for the same
amount of time. Nicolas also reported similar test results after testing a
kernel with the patch applied.

This is sent first as an RFC to both LKML and systemd mailing lists since
the uevent call has been like this in the module loader for more than a
decade (since v2.6), I would be cautious as to not break anything that
actually relies on the current behavior for whatever reason. More testing
would be greatly appreciated.

Thanks,

Jessica

Jessica Yu (1):
  module: delay kobject uevent until after module init call

 kernel/module.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


             reply	other threads:[~2020-12-03 13:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 13:51 Jessica Yu [this message]
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

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=20201203135124.16695-1-jeyu@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox