From: Tadeusz Struk <tadeusz.struk@linaro.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: kernel BUG in ext4_writepages
Date: Thu, 19 May 2022 16:14:17 -0700 [thread overview]
Message-ID: <e9ccb919-1616-f94f-c465-7024011ad8e5@linaro.org> (raw)
In-Reply-To: <20220519122353.eqpnxiaybvobfszb@quack3.lan>
On 5/19/22 05:23, Jan Kara wrote:
> Hi!
>
> On Tue 10-05-22 15:28:38, Tadeusz Struk wrote:
>> Syzbot found another BUG in ext4_writepages [1].
>> This time it complains about inode with inline data.
>> C reproducer can be found here [2]
>> I was able to trigger it on 5.18.0-rc6
>>
>> [1] https://syzkaller.appspot.com/bug?id=a1e89d09bbbcbd5c4cb45db230ee28c822953984
>> [2] https://syzkaller.appspot.com/text?tag=ReproC&x=129da6caf00000
>
> Thanks for report. This should be fixed by:
>
> https://lore.kernel.org/all/20220516012752.17241-1-yebin10@huawei.com/
In case of the syzbot bug there is something messed up with PAGE DIRTY flags
and the way syzbot sets up the write. This is what triggers the crash:
$ ftrace -f ./repro
...
[pid 2395] open("./bus", O_RDWR|O_CREAT|O_SYNC|O_NOATIME, 000 <unfinished ...>
[pid 2395] <... open resumed> ) = 6
...
[pid 2395] write(6, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 22 <unfinished ...>
...
[pid 2395] <... write resumed> ) = 22
One way I could fix it was to clear the PAGECACHE_TAG_DIRTY on the mapping in
ext4_try_to_write_inline_data() after the page has been updated:
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 9c076262770d..e4bbb53fa26f 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -715,6 +715,7 @@ int ext4_try_to_write_inline_data(struct address_space *mapping,
put_page(page);
goto out_up_read;
}
+ __xa_clear_mark(&mapping->i_pages, 0, PAGECACHE_TAG_DIRTY);
}
ret = 1;
Please let me know it if makes sense any I will send a proper patch.
--
Thanks,
Tadeusz
next prev parent reply other threads:[~2022-05-19 23:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 22:28 kernel BUG in ext4_writepages Tadeusz Struk
2022-05-19 12:23 ` Jan Kara
2022-05-19 15:40 ` Tadeusz Struk
2022-05-19 23:14 ` Tadeusz Struk [this message]
2022-05-20 9:50 ` Jan Kara
2022-05-20 14:50 ` Tadeusz Struk
2022-07-26 22:44 ` [PATCH] ext4: try to flush inline data before calling BUG in writepages Tadeusz Struk
2022-07-27 15:57 ` Jan Kara
2022-07-27 17:25 ` Lukas Czerner
2022-07-27 17:40 ` Tadeusz Struk
2022-07-27 17:51 ` Lukas Czerner
[not found] <000000000000c3a53d05de992007@google.com>
2022-11-07 12:37 ` kernel BUG in ext4_writepages syzbot
2022-11-07 14:08 ` Jan Kara
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=e9ccb919-1616-f94f-c465-7024011ad8e5@linaro.org \
--to=tadeusz.struk@linaro.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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).