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]
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ