linux-ext4 - Re: [Cluster-devel] iomap preparations for GFS2 v2

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Jun 2018 16:35:50 +0200
From:   Christoph Hellwig <hch@....de>
To:     Andreas Gruenbacher <agruenba@...hat.com>
Cc:     Steven Whitehouse <swhiteho@...hat.com>,
        Christoph Hellwig <hch@....de>,
        cluster-devel <cluster-devel@...hat.com>,
        linux-xfs@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [Cluster-devel] iomap preparations for GFS2 v2

On Tue, Jun 19, 2018 at 01:08:12PM +0200, Andreas Gruenbacher wrote:
> What I'm seeing in the readpage address space operation is pages which
> are not PageUptodate(), with a page-size buffer head that is
> buffer_uptodate(). The filesystem doesn't bother keeping the page
> flags in sync with the buffer head flags, nothing unusual.

It is in fact highly unusual, as all the generic routines do set
the page uptodate once all buffers are uptodate.

> When
> iomap_readpage is called on such a page, it will replace the current
> contents with what's on disk, losing the changes in memory. So we
> cannot just call iomap_readpages, we need to check the buffer head
> flags as well. Or, since the old code is still needed for page size !=
> block size anyway, we can fall back to that for pages that have
> buffers for now.

I'd like to understand where that buffer_head comes from, something
seems fishy here.