From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Ivan Zahariev <famzah@icdsoft.com>,
linux-ext4@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: kernel BUG at fs/ext4/inode.c:1914 - page_buffers()
Date: Wed, 15 Mar 2023 14:57:11 -0400 [thread overview]
Message-ID: <20230315185711.GB3024297@mit.edu> (raw)
In-Reply-To: <20230315173217.to44byhvg6baf7ai@quack3>
On Wed, Mar 15, 2023 at 06:32:17PM +0100, Jan Kara wrote:
> On Wed 15-03-23 13:27:11, Ivan Zahariev wrote:
> > On 12.1.2023 г. 17:07, Jan Kara wrote:
> > > So after a bit of thought I agree that the commit 5c48a7df91499 ("ext4: fix
> > > an use-after-free issue about data=journal writeback mode") is broken. The
> > > problem is when we unlock the page in __ext4_journalled_writepage() anybody
> > > else can come, writeout the page, and reclaim page buffers (due to memory
> > > pressure). Previously, bh references were preventing the buffer reclaim to
> > > happen but now there's nothing to prevent it.
> > >
> > > My rewrite of data=journal writeback path fixes this problem as a
> > > side-effect but perhaps we need a quickfix for stable kernels? Something
> > > like attached patch?
> > >
> > > Honza
> >
> > Do you consider this patch production ready?
>
> Ah, the patch has likely fallen through the cracks because I waited for
> some reply and then forgot about it and Ted likely missed it inside the
> thread. But yes I consider the patch safe to test on production machines -
> at least it has passed testing with fstests on my test VM without any
> visible issues.
Yeah, sorry, I didn't see it since it was in an attachment as opposed
to with an explicit [PATCH] subject line.
And at this point, the data=journal writeback patches have landed in
the ext4/dev tree, and while we could try to see if we could land this
before the next merge window, I'm worried about merge or semantic
conflicts of having both patches in a tree at one time.
I guess we could send it to Linus, let it get backported into stable,
and then revert it during the merge window, ahead of applying the
data=journal cleanup patch series. But that seems a bit ugly. Or we
could ask for an exception from the stable kernel folks, after I do a
full set of xfstests runs on it. (Of course, I don't think anyone has
been able to create a reliable reproducer, so all we can do is to test
for regression failures.)
Jan, Greg, what do you think?
- Ted
next prev parent reply other threads:[~2023-03-15 18:57 UTC|newest]
Thread overview: 15+ 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
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 [this message]
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
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=20230315185711.GB3024297@mit.edu \
--to=tytso@mit.edu \
--cc=famzah@icdsoft.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--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 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).