linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Pen <r.peniaev@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Roman Pen <r.peniaev@gmail.com>,
	Ming Lei <ming.lei@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: [v4 PATCH 1/1] init: fix race between rootfs mount and firmware loading
Date: Fri, 19 Sep 2014 21:44:24 +0900	[thread overview]
Message-ID: <1411130664-10195-1-git-send-email-r.peniaev@gmail.com> (raw)
In-Reply-To: <20140918174127.GB340@redhat.com>

The thing is that built-in modules are being inited before
rootfs mount.  Some of the modules can request firmware loading
from another thread using async 'request_firmware_nowait' call
on inition, so we can catch this kind of race:
   rootfs does not exist yet, but we are going to open and load
   firmware file requesting it from the kernel thread.

Solution is simple: before any rootfs access firmware loader
must wait for rootfs mount.

There are few questions which remain unanswered, but in this
patch I do not want to complicate things and want to fix exactly
the race.  So here are the questions:

1. can 'request_firmware' (sync variant) be called on module inition
   directly, without any threads? if can, that means firmware will
   never be loaded for the driver at first try in case of built-in
   module, because rootfs will be mounted only at the end of kernel
   init sequence.

2. in case of separated '/lib' mount point we still have the problem:
   firmware will be loaded only on further tries, but the first attempt
   will always fail, because '/lib' mount point does not exist.  Seems
   to me this can't be simply fixed, and firmware_request logic needs
   some refactoring.

Probably, there are other good questions which I do not see because
of shallow understanding of init and firmware loading sequences.

Signed-off-by: Roman Pen <r.peniaev@gmail.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: linux-kernel@vger.kernel.org
---
 drivers/base/firmware_class.c |  6 ++++++
 include/linux/init.h          |  1 +
 init/main.c                   | 33 +++++++++++++++++++++++++++++++--
 3 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index bf42430..450c4ae 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -29,6 +29,7 @@
 #include <linux/syscore_ops.h>
 #include <linux/reboot.h>
 #include <linux/security.h>
+#include <linux/init.h>
 
 #include <generated/utsrelease.h>
 
@@ -324,6 +325,11 @@ static int fw_get_filesystem_firmware(struct device *device,
 	int rc = -ENOENT;
 	char *path = __getname();
 
+	/* Before any file access we have to wait for rootfs.
+	   In case of built-in module we can race with kernel init
+	   thread, which has not mounted rootfs yet */
+	wait_for_rootfs();
+
 	for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
 		struct file *file;
 
diff --git a/include/linux/init.h b/include/linux/init.h
index 2df8e8d..83233ae 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -152,6 +152,7 @@ void setup_arch(char **);
 void prepare_namespace(void);
 void __init load_default_modules(void);
 int __init init_rootfs(void);
+void wait_for_rootfs(void);
 
 extern void (*late_time_init)(void);
 
diff --git a/init/main.c b/init/main.c
index bb1aed9..2cfe187 100644
--- a/init/main.c
+++ b/init/main.c
@@ -973,6 +973,33 @@ static int __ref kernel_init(void *unused)
 	      "See Linux Documentation/init.txt for guidance.");
 }
 
+static DECLARE_WAIT_QUEUE_HEAD(rootfs_waitq);
+static bool rootfs_mounted;
+
+void wait_for_rootfs(void)
+{
+	/* Here we try to protect from a few things:
+	 * 1. Avoid waiting for ourselves, when init thread has not
+	 *    mounted rootfs yet.
+	 * 2. Avoid warning if call chain was initiated from userspace
+	 *    /sbin/init. For example when /sbin/init loads the driver,
+	 *    which, in turn, wants to access rootfs (e.g. firmware loading),
+	 *    thus it has to be sure, that rootfs has been successfully
+	 *    mounted.
+	 */
+	if (rootfs_mounted || WARN_ON(is_global_init(current)))
+		return;
+	else
+		wait_event(rootfs_waitq, rootfs_mounted);
+}
+EXPORT_SYMBOL(wait_for_rootfs);
+
+static inline void wake_up_rootfs_waiters(void)
+{
+	rootfs_mounted = true;
+	wake_up_all(&rootfs_waitq);
+}
+
 static noinline void __init kernel_init_freeable(void)
 {
 	/*
@@ -1025,9 +1052,11 @@ static noinline void __init kernel_init_freeable(void)
 
 	/*
 	 * Ok, we have completed the initial bootup, and
-	 * we're essentially up and running. Get rid of the
-	 * initmem segments and start the user-mode stuff..
+	 * we're essentially up and running.  Wake up the
+	 * rootfs mount waiters, get rid of the initmem
+	 * segments, and start the user-mode stuff..
 	 */
+	wake_up_rootfs_waiters();
 
 	/* rootfs is available now, try loading default modules */
 	load_default_modules();
-- 
2.0.0


  parent reply	other threads:[~2014-09-19 12:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 14:45 [PATCH 1/1] init: fix race between rootfs mount and firmware loading Roman Pen
2014-09-15 16:39 ` Oleg Nesterov
2014-09-17 13:18   ` Roman Peniaev
2014-09-17 13:28     ` [v2 PATCH " Roman Pen
2014-09-17 17:46       ` Oleg Nesterov
2014-09-18 13:31         ` Roman Peniaev
2014-09-18 17:28           ` Oleg Nesterov
2014-09-18 13:33         ` [v3 " Roman Pen
2014-09-18 17:41           ` Oleg Nesterov
2014-09-19 12:41             ` Roman Peniaev
2014-09-19 18:03               ` Oleg Nesterov
2014-09-19 12:44             ` Roman Pen [this message]
2014-09-19 19:45               ` [v4 " Oleg Nesterov
2014-09-20 13:20                 ` Roman Peniaev
2014-09-19 21:42               ` Greg Kroah-Hartman
2014-09-20 13:18                 ` Roman Peniaev
2014-09-20 14:42                   ` Greg Kroah-Hartman
2014-09-20 15:12                     ` Roman Peniaev
2014-09-17 17:59     ` [PATCH " Oleg Nesterov

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=1411130664-10195-1-git-send-email-r.peniaev@gmail.com \
    --to=r.peniaev@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=oleg@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).