linux-kernel - Re: [RFC PATCH V3] iomap: add support to track dirty state of sub pages

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: <20200822164334.GA2625@infradead.org>
Date:   Sat, 22 Aug 2020 17:43:34 +0100
From:   Christoph Hellwig <hch@...radead.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        "yukuai (C)" <yukuai3@...wei.com>,
        Gao Xiang <hsiangkao@...hat.com>, darrick.wong@...cle.com,
        david@...morbit.com, linux-xfs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        yi.zhang@...wei.com
Subject: Re: [RFC PATCH V3] iomap: add support to track dirty state of sub
 pages

On Sat, Aug 22, 2020 at 03:24:14PM +0100, Matthew Wilcox wrote:
> The case I was worrying about:
> 
> fill a filesystem so that free space is very fragmented
> readahead into a hole
> hole is large, don't allocate an iop
> writeback the page
> don't have an iop, can't track the write count
> 
> I'd be fine with choosing to allocate an iop later (and indeed I do that
> as part of the THP work).  But does this scenario make you think of any
> other corner cases?

Can't think of a corner case.  And as said last time this comes up I
think trying to allocate the iop as late and lazy as possible is
probably a good thing.  I just went for the dumb way because it was
simpler and already a huge improvement over buffer heads.