From: Hawkins Jiawei <yin31149@gmail.com>
To: dvyukov@google.com
Cc: paskripkin@gmail.com, syzkaller-bugs@googlegroups.com,
linux-kernel@vger.kernel.org, willy@infradead.org,
syzkaller@googlegroups.com, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org,
Hawkins Jiawei <yin31149@gmail.com>,
linux-kernel-mentees@lists.linuxfoundation.org,
syzbot+2af3bc9585be7f23f290@syzkaller.appspotmail.com
Subject: [PATCH] fs: fix WARNING in mark_buffer_dirty (4)
Date: Sun, 21 Aug 2022 20:10:39 +0800 [thread overview]
Message-ID: <20220821121038.3527-1-yin31149@gmail.com> (raw)
In-Reply-To: <CACT4Y+bUtBuhD7_BAN+NavEfhBNOavqF0CJkrZ+Gc4pYeLiy+g@mail.gmail.com>
Syzkaller reports bug as follows:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 3684 at fs/buffer.c:1081 mark_buffer_dirty+0x59d/0xa20 fs/buffer.c:1081
[...]
Call Trace:
<TASK>
minix_put_super+0x199/0x500 fs/minix/inode.c:49
generic_shutdown_super+0x14c/0x400 fs/super.c:462
kill_block_super+0x97/0xf0 fs/super.c:1394
deactivate_locked_super+0x94/0x160 fs/super.c:332
deactivate_super+0xad/0xd0 fs/super.c:363
cleanup_mnt+0x3a2/0x540 fs/namespace.c:1186
task_work_run+0xdd/0x1a0 kernel/task_work.c:177
ptrace_notify+0x114/0x140 kernel/signal.c:2353
ptrace_report_syscall include/linux/ptrace.h:420 [inline]
ptrace_report_syscall_exit include/linux/ptrace.h:482 [inline]
syscall_exit_work kernel/entry/common.c:249 [inline]
syscall_exit_to_user_mode_prepare+0x129/0x280 kernel/entry/common.c:276
__syscall_exit_to_user_mode_work kernel/entry/common.c:281 [inline]
syscall_exit_to_user_mode+0x9/0x50 kernel/entry/common.c:294
do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
</TASK>
------------------------------------
During VFS releasing the minix's superblock, kernel will calls
sync_filesystem() to write out and wait upon all dirty data
associated with this superblock.
Yet the problem is that this write may fail, then kernel will
clear BH_Uptodate flag in superblock's struct buffer_head
in end_buffer_async_write(). When kernel returns from
sync_filesystem() and calls sop->put_super()
(which is minix_put_super()), it will triggers the warning
for struct buffer_head is not uptodate in mark_buffer_dirty().
This patch solves it by handling sync_filesystem() write error
in minix_put_super(), before calling mark_buffer_dirty()
Reported-and-tested-by: syzbot+2af3bc9585be7f23f290@syzkaller.appspotmail.com
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
---
fs/minix/inode.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/fs/minix/inode.c b/fs/minix/inode.c
index da8bdd1712a7..8e9a8057dcfe 100644
--- a/fs/minix/inode.c
+++ b/fs/minix/inode.c
@@ -42,17 +42,27 @@ static void minix_put_super(struct super_block *sb)
{
int i;
struct minix_sb_info *sbi = minix_sb(sb);
+ struct buffer_head *sbh = sbi->s_sbh;
if (!sb_rdonly(sb)) {
if (sbi->s_version != MINIX_V3) /* s_state is now out from V3 sb */
sbi->s_ms->s_state = sbi->s_mount_state;
- mark_buffer_dirty(sbi->s_sbh);
+
+ lock_buffer(sbh);
+ if (buffer_write_io_error(sbh)) {
+ clear_buffer_write_io_error(sbh);
+ set_buffer_uptodate(sbh);
+ printk("MINIX-fs warning: superblock detected "
+ "previous I/O error\n");
+ }
+ mark_buffer_dirty(sbh);
+ unlock_buffer(sbh);
}
for (i = 0; i < sbi->s_imap_blocks; i++)
brelse(sbi->s_imap[i]);
for (i = 0; i < sbi->s_zmap_blocks; i++)
brelse(sbi->s_zmap[i]);
- brelse (sbi->s_sbh);
+ brelse (sbh);
kfree(sbi->s_imap);
sb->s_fs_info = NULL;
kfree(sbi);
--
2.25.1
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
parent reply other threads:[~2022-08-21 12:11 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CACT4Y+bUtBuhD7_BAN+NavEfhBNOavqF0CJkrZ+Gc4pYeLiy+g@mail.gmail.com>]
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=20220821121038.3527-1-yin31149@gmail.com \
--to=yin31149@gmail.com \
--cc=dvyukov@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paskripkin@gmail.com \
--cc=syzbot+2af3bc9585be7f23f290@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=syzkaller@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).