From: "Theodore Ts'o" <tytso@mit.edu>
To: Ivan Zahariev <famzah@icdsoft.com>
Cc: linux-ext4@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: kernel BUG at fs/ext4/inode.c:1914 - page_buffers()
Date: Mon, 5 Dec 2022 16:10:47 -0500 [thread overview]
Message-ID: <Y45eV/nA2tj8C94W@mit.edu> (raw)
In-Reply-To: <c9e47bc3-3c5f-09ae-9dcc-eb5957d78b1b@icdsoft.com>
On Wed, Nov 23, 2022 at 04:48:01PM +0200, Ivan Zahariev wrote:
> Hello,
>
> Starting with kernel 5.15 for the past eight months we have a total of 12
> kernel panics at a fleet of 1000 KVM/Qemu machines which look the following
> way:
>
> kernel BUG at fs/ext4/inode.c:1914
>
> Switching from kernel 4.14 to 5.15 almost immediately triggered the problem.
> Therefore we are very confident that userland activity is more or less the
> same and is not the root cause. The kernel function which triggers the BUG
> is __ext4_journalled_writepage(). In 5.15 the code for
> __ext4_journalled_writepage() in "fs/ext4/inode.c" is the same as the
> current kernel "master". The line where the BUG is triggered is:
>
> struct buffer_head *page_bufs = page_buffers(page)
...
>
> Back to the problem! 99% of the difference between 4.14 and the latest
> kernel for __ext4_journalled_writepage() in "fs/ext4/inode.c" comes from the
> following commit: https://github.com/torvalds/linux/commit/5c48a7df91499e371ef725895b2e2d21a126e227
>
> Is it safe that we revert this patch on the latest 5.15 kernel, so that we
> can confirm if this resolves the issue for us?
No, it's not safe to revert this patch; this fixes a potential
use-after-free bug identified by Syzkaller (and use-after-frees can
sometimes be leveraged into security volunerabilities.
I have not tested this change yet, but looking at the code and the
change made in patch yet, this *might* be a possible fix:
size = i_size_read(inode);
- if (page->mapping != mapping || page_offset(page) > size) {
+ if (page->mapping != mapping || page_offset(page) >= size) {
/* The page got truncated from under us */
ext4_journal_stop(handle);
ret = 0;
goto out;
}
Is it fair to say that your workload is using data=journaled and is
frequently truncating that might have been recently modified (hence
triggering the race between truncate and journalled writepages)?
I wonder if you could come up with a more reliable reproducer so we
can test a particular patch.
Thanks,
- Ted
next prev parent reply other threads:[~2022-12-05 21:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 14:48 kernel BUG at fs/ext4/inode.c:1914 - page_buffers() Ivan Zahariev
2022-12-05 17:27 ` Ivan Zahariev
2022-12-05 21:10 ` Theodore Ts'o [this message]
2022-12-05 21:50 ` Ivan Zahariev
2023-01-12 15:07 ` Jan Kara
2023-03-15 11:27 ` Ivan Zahariev
2023-03-15 17:32 ` Jan Kara
2023-03-15 18:57 ` Theodore Ts'o
2023-05-11 9:21 ` Marcus Hoffmann
2023-05-12 12:19 ` Greg KH
2023-05-12 14:24 ` Marcus Hoffmann
2023-05-12 22:50 ` Greg KH
2023-05-15 9:10 ` Jan Kara
2023-09-20 9:40 ` Mathieu Othacehe
2023-09-22 9:54 ` Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2023-10-04 9:37 Mathieu Othacehe
2023-10-04 10:10 ` Sasha Levin
2023-10-05 3:54 ` Theodore Ts'o
2023-10-05 7:08 ` Mathieu Othacehe
2023-10-06 9:15 ` 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=Y45eV/nA2tj8C94W@mit.edu \
--to=tytso@mit.edu \
--cc=famzah@icdsoft.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-ext4@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.