Re: [RFC PATCH v2 7/7] ext4: fix race between blkdev_releasepage() and ext4_put_super()

[Jan Kara <jack@suse.cz>]

On Fri 23-04-21 19:39:09, Zhang Yi wrote:
> On 2021/4/22 17:04, Jan Kara wrote:
> > I'm OK with that because mainly for IO error reporting it makes sense to
> > me. For this memory reclaim problem I think we have also other reasonably
> > sensible options. E.g. we could have a shrinker that would just walk the
> > checkpoint list and reclaim journal heads for whatever is already written
> > out... Or we could just release journal heads already after commit and
> > during checkpoint we'd fetch the list of blocks that may need to be written
> > out e.g. from journal descriptor blocks. This would be a larger overhaul
> > but as a bonus we'd get rid of probably the last place in the kernel which
> > can write out page contents through buffer heads without updating page
> > state properly (and thus get rid of some workarounds in mm code as well).
> 
> Thanks for these suggestions, I get your first solution and sounds good, but
> I do not understand your last sentence, how does ext4 not updating page state
> properly? Could you explain it more clearly?

The problem with current checkpointing code is that it writes out dirty
buffer heads through submit_bh() function without updating page dirty state
or without setting PageWriteback bit (because we cannot easily grab page
lock in those places due to lock ordering). Thus we can end up with a page
that is dirty but in fact does not hold any dirty data (none of the buffer
heads is dirty) and also locking a page and checking for PageWriteback
isn't enough to be sure page is not under IO. This is ugly and requires
some workarounds in MM code...

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