From: Jan Kara <jack@suse.cz>
To: Petr Mladek <pmladek@suse.com>
Cc: Jan Kara <jack@suse.cz>, Ted Tso <tytso@mit.edu>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: Avoid panic during forced reboot
Date: Wed, 13 Mar 2019 15:40:12 +0100 [thread overview]
Message-ID: <20190313144012.GE9108@quack2.suse.cz> (raw)
In-Reply-To: <20190313102514.u66q5u7bdhjkr7pa@pathway.suse.cz>
On Wed 13-03-19 11:25:14, Petr Mladek wrote:
> On Tue 2019-03-12 17:01:39, Jan Kara wrote:
> > On Tue 12-03-19 13:21:06, Petr Mladek wrote:
> > > On Tue 2019-03-12 10:49:06, Jan Kara wrote:
> > > > When admin calls "reboot -f" - i.e., does a hard system reboot by
> > > > directly calling reboot(2) - ext4 filesystem mounted with errors=panic
> > > > can panic the system. This happens because the underlying device gets
> > > > disabled without unmounting the filesystem and thus some syscall running
> > > > in parallel to reboot(2) can result in the filesystem getting IO errors.
> > > >
> > > > This is somewhat surprising to the users so try improve the behavior by
> > > > switching to errors=remount-ro behavior when the system is running
> > > > reboot(2).
> > > >
> > > > @@ -460,7 +466,12 @@ static void ext4_handle_error(struct super_block *sb)
> > > > if (journal)
> > > > jbd2_journal_abort(journal, -EIO);
> > > > }
> > > > - if (test_opt(sb, ERRORS_RO)) {
> > > > + /*
> > > > + * We force ERRORS_RO behavior when system is rebooting. Otherwise we
> > > > + * could panic during 'reboot -f' as the underlying device got already
> > > > + * disabled.
> > > > + */
> > > > + if (test_opt(sb, ERRORS_RO) || system_going_down()) {
> > >
> > > If I read the code correctly then this will not avoid the panic().
> >
> > No, you are right. Attached is a fixed up patch.
>
> > >From 15b830d4e877ed908c733ab3219801d1026af256 Mon Sep 17 00:00:00 2001
> > From: Jan Kara <jack@suse.cz>
> > Date: Tue, 12 Mar 2019 10:38:19 +0100
> > Subject: [PATCH] ext4: Avoid panic during forced reboot
> >
> > When admin calls "reboot -f" - i.e., does a hard system reboot by
> > directly calling reboot(2) - ext4 filesystem mounted with errors=panic
> > can panic the system. This happens because the underlying device gets
> > disabled without unmounting the filesystem and thus some syscall running
> > in parallel to reboot(2) can result in the filesystem getting IO errors.
> >
> > This is somewhat surprising to the users so try improve the behavior by
> > switching to errors=remount-ro behavior when the system is running
> > reboot(2).
> >
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > ---
> > fs/ext4/super.c | 16 +++++++++++++---
> > 1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > index 60da0a6e4d86..b7b621d5d87a 100644
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> > @@ -430,6 +430,12 @@ static void ext4_journal_commit_callback(journal_t *journal, transaction_t *txn)
> > spin_unlock(&sbi->s_md_lock);
> > }
> >
> > +static bool system_going_down(void)
> > +{
> > + return system_state == SYSTEM_HALT || system_state == SYSTEM_POWER_OFF
> > + || system_state == SYSTEM_RESTART;
> > +}
> > +
> > /* Deal with the reporting of failure conditions on a filesystem such as
> > * inconsistencies detected or read IO failures.
> > *
> > @@ -460,7 +466,12 @@ static void ext4_handle_error(struct super_block *sb)
> > if (journal)
> > jbd2_journal_abort(journal, -EIO);
> > }
> > - if (test_opt(sb, ERRORS_RO)) {
> > + /*
> > + * We force ERRORS_RO behavior when system is rebooting. Otherwise we
> > + * could panic during 'reboot -f' as the underlying device got already
> > + * disabled.
> > + */
> > + if (test_opt(sb, ERRORS_RO) || system_going_down()) {
> > ext4_msg(sb, KERN_CRIT, "Remounting filesystem read-only");
> > /*
> > * Make sure updated value of ->s_mount_flags will be visible
> > @@ -468,8 +479,7 @@ static void ext4_handle_error(struct super_block *sb)
> > */
> > smp_wmb();
> > sb->s_flags |= SB_RDONLY;
> > - }
> > - if (test_opt(sb, ERRORS_PANIC)) {
> > + } else if (test_opt(sb, ERRORS_PANIC)) {
>
> I think that this would work. Just note that it changes a bit
> the semantic also when the system is in the running state.
>
> ERRORS_RO option always takes precedence over ERRORS_PANIC now.
> It was the other way before.
I know. But they couldn't be set both at the same time so this should not
matter.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2019-03-13 14:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-12 9:49 [PATCH] ext4: Avoid panic during forced reboot Jan Kara
2019-03-12 12:21 ` Petr Mladek
2019-03-12 16:01 ` Jan Kara
2019-03-13 10:25 ` Petr Mladek
2019-03-13 14:40 ` Jan Kara [this message]
2019-03-15 3:47 ` Theodore Ts'o
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=20190313144012.GE9108@quack2.suse.cz \
--to=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=tytso@mit.edu \
/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).