Date:   Wed, 15 Mar 2023 18:32:17 +0100
From:   Jan Kara <jack@suse.cz>
To:     Ivan Zahariev <famzah@icdsoft.com>
Cc:     Jan Kara <jack@suse.cz>, Theodore Ts'o <tytso@mit.edu>,
        linux-ext4@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: kernel BUG at fs/ext4/inode.c:1914 - page_buffers()
Message-ID: <20230315173217.to44byhvg6baf7ai@quack3>
References: <c9e47bc3-3c5f-09ae-9dcc-eb5957d78b1b@icdsoft.com>
 <Y45eV/nA2tj8C94W@mit.edu>
 <20230112150708.y2ws5q3wu2xxow3p@quack3>
 <ea6a88c7-5603-af1d-e775-0857fc605224@icdsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ea6a88c7-5603-af1d-e775-0857fc605224@icdsoft.com>
Precedence: bulk

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.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR