From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, Jaegeuk Kim <jaegeuk@google.com>,
"Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: handle errors on ext4_commit_super
Date: Thu, 19 Apr 2018 08:58:18 -0700 [thread overview]
Message-ID: <20180419155818.GA81439@jaegeuk-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <20180419151853.jtif7ncjuhf6yuwl@quack2.suse.cz>
Hi Jan,
Thank you for the review.
On 04/19, Jan Kara wrote:
> On Thu 29-03-18 18:44:29, Jaegeuk Kim wrote:
> > From: Jaegeuk Kim <jaegeuk@google.com>
> >
> > When remounting ext4 from ro to rw, currently it allows its transition,
> > even if ext4_commit_super() returns EIO. Even worse thing is, after that,
> > fs/buffer complains buffer dirty bits like:
> >
> > Call trace:
> > [<ffffff9750c259dc>] mark_buffer_dirty+0x184/0x1a4
> > [<ffffff9750cb398c>] __ext4_handle_dirty_super+0x4c/0xfc
> > [<ffffff9750c7a9fc>] ext4_file_open+0x154/0x1c0
> > [<ffffff9750bea51c>] do_dentry_open+0x114/0x2d0
> > [<ffffff9750bea75c>] vfs_open+0x5c/0x94
> > [<ffffff9750bf879c>] path_openat+0x668/0xfe8
> > [<ffffff9750bf8088>] do_filp_open+0x74/0x120
> > [<ffffff9750beac98>] do_sys_open+0x148/0x254
> > [<ffffff9750beade0>] SyS_openat+0x10/0x18
> > [<ffffff9750a83ab0>] el0_svc_naked+0x24/0x28
> > EXT4-fs (dm-1): previous I/O error to superblock detected
> > Buffer I/O error on dev dm-1, logical block 0, lost sync page write
> > EXT4-fs (dm-1): re-mounted. Opts: (null)
> > Buffer I/O error on dev dm-1, logical block 80, lost async page write
> >
> > Cc: "Theodore Ts'o" <tytso@mit.edu>
> > Cc: Andreas Dilger <adilger.kernel@dilger.ca>
> > Cc: linux-ext4@vger.kernel.org
> > Cc: Jaegeuk Kim <jaegeuk@kernel.org>
> > Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
> > ---
> > fs/ext4/super.c | 21 +++++++++++++--------
> > 1 file changed, 13 insertions(+), 8 deletions(-)
>
> Thanks for the patch. Some comments below.
>
> >
> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > index 39bf464c35f1..b268bfea879c 100644
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> > @@ -2151,7 +2151,7 @@ static int ext4_setup_super(struct super_block *sb, struct ext4_super_block *es,
> > if (sbi->s_journal)
> > ext4_set_feature_journal_needs_recovery(sb);
> >
> > - ext4_commit_super(sb, 1);
> > + res = ext4_commit_super(sb, 1);
> > done:
> > if (test_opt(sb, DEBUG))
> > printk(KERN_INFO "[EXT4 FS bs=%lu, gc=%u, "
>
> So return value of ext4_setup_super() looks a bit strange and it seems it
> currently returns 0 or SB_RDONLY. So I think you first need to clean this
Indeed. I'll update it in v2.
> up before making ext4_setup_super() return error code (as your patch could
> make ext4_fill_super() return SB_RDONLY under some circumstances).
Interestingly, it only affects ext4_remount() only. :P
>
> > @@ -4739,11 +4739,10 @@ static int ext4_commit_super(struct super_block *sb, int sync)
> > unlock_buffer(sbh);
> > error = __sync_dirty_buffer(sbh,
> > REQ_SYNC | (test_opt(sb, BARRIER) ? REQ_FUA : 0));
> > - if (error)
> > + if (error && !buffer_write_io_error(sbh))
> > return error;
> >
> > - error = buffer_write_io_error(sbh);
> > - if (error) {
> > + if (buffer_write_io_error(sbh)) {
> > ext4_msg(sb, KERN_ERR, "I/O error while writing "
> > "superblock");
> > clear_buffer_write_io_error(sbh);
>
> I'd rather rewrite this as:
> if (buffer_write_io_error(sbh)) {
> do stuff as now
> }
> if (error)
> return error;
Got it.
Thanks,
>
> Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
next prev parent reply other threads:[~2018-04-19 15:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-30 1:44 Jaegeuk Kim
2018-04-19 15:18 ` Jan Kara
2018-04-19 15:58 ` Jaegeuk Kim [this message]
2018-04-19 15:59 ` [PATCH v2] " Jaegeuk Kim
2018-04-21 13:12 ` Jan Kara
2018-04-23 14:46 ` [PATCH v3] " Jaegeuk Kim
2018-05-14 3:46 ` Theodore Y. 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=20180419155818.GA81439@jaegeuk-macbookpro.roam.corp.google.com \
--to=jaegeuk@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=jaegeuk@google.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®