lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210423160647.GE8755@quack2.suse.cz>
Date:   Fri, 23 Apr 2021 18:06:47 +0200
From:   Jan Kara <jack@...e.cz>
To:     Zhang Yi <yi.zhang@...wei.com>
Cc:     Jan Kara <jack@...e.cz>, Theodore Ts'o <tytso@....edu>,
        Christoph Hellwig <hch@...radead.org>,
        linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        adilger.kernel@...ger.ca, yukuai3@...wei.com
Subject: Re: [RFC PATCH v2 7/7] ext4: fix race between blkdev_releasepage()
 and ext4_put_super()

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@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ