From: Plamen Petrov <plamen.sisi@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH] do_mounts: try all available filesystems before panicking
Date: Mon, 5 May 2014 21:34:49 +0300 [thread overview]
Message-ID: <1399314889-9829-1-git-send-email-plamen.sisi@gmail.com> (raw)
While debugging a kernel panic with 3.14.1 it became clear that some
filesystems' mount routines give back return codes other than zero, EACCES
or EINVAL. Such return codes can result in panic during boot before the kernel
tries to mount root with all of the available filesystems, as can be seen in
bugzilla entries 74901 and 74261.
Make mount_block_root continue trying other available filesystems by default,
not only when the last tried returned EACCES or EINVAL.
Cc: stable@vger.kernel.org
Signed-off-by: Plamen Petrov <plamen.sisi@gmail.com>
---
The story short: on systems with btrfs root I have a kernel .config with ext4,
xfs and btrfs built-in which works fine with 3.13.x, but 3.14.x panics. After
inserting some debug printks, I got this info from mount_block_root:
---> EACCESS=13, EINVAL=22, Available filesystems: ext3 ext2 ext4 fuseblk xfs btrfs
-----> Tried ext3, error code is -22.
-----> Tried ext2, error code is -22.
-----> Tried ext4, error code is -22.
-----> Tried fuseblk, error code is -22.
-----> Tried xfs, error code is -38.
VFS: Cannot open root device "sda2" or unknown-block(8,2): error -38
Please append a correct "root=" boot option; here are the available partitions:
Last one tried is xfs, the needed btrfs in this case never gets a chance.
Looking at the code in init/do_mounts.c we can see that it "continue"s only if
the return code it got is EINVAL, yet xfs clearly does not fit - so the kernel
panics. Maybe there are other filesystems like xfs - I did not check. This
patch fixes mount_block_root to try all available filesystems first, and then
panic. The patched 3.14.x works for me.
This patch was sent to LKML once, see
http://article.gmane.org/gmane.linux.kernel/1691881
Maybe the first time around it got damaged by my mail client, lost in all of
the LKML traffic, or nobody picked it up, because scripts/get_maintainer.pl
said "Send it to LKML" only, and I did just that.
Either way - resending and CC-ing Linus, with stable- added as CC to the patch
as well.
init/do_mounts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 82f2288..979bd71 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -396,7 +396,7 @@ retry:
case -EACCES:
flags |= MS_RDONLY;
goto retry;
- case -EINVAL:
+ default:
continue;
}
/*
--
1.9.0
next reply other threads:[~2014-05-05 18:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 18:34 Plamen Petrov [this message]
2014-05-25 20:04 ` Linus Torvalds
2014-05-25 21:11 ` Theodore Ts'o
2014-05-26 2:40 ` Dave Chinner
2014-05-26 0:08 ` Dave Chinner
2014-05-26 1:19 ` Dave Chinner
2014-05-26 4:19 ` Dave Chinner
2014-05-26 5:18 ` Пламен Петров
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=1399314889-9829-1-git-send-email-plamen.sisi@gmail.com \
--to=plamen.sisi@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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
all inboxes | Powered by JetHome®