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
