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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200107181751.GB917713@magnolia>
Date:   Tue, 7 Jan 2020 10:17:51 -0800
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     "yukuai (C)" <yukuai3@...wei.com>
Cc:     bfoster@...hat.com, dchinner@...hat.com, sandeen@...deen.net,
        cmaiolino@...hat.com, hch@....de, linux-xfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, zhengbin13@...wei.com,
        yi.zhang@...wei.com, houtao1@...wei.com
Subject: Re: [PATCH 2/2] xfs: fix stale data exposure problem when punch
 hole, collapse range or zero range across a delalloc extent

On Tue, Jan 07, 2020 at 10:09:44AM +0800, yukuai (C) wrote:
> 
> 
> On 2020/1/7 5:57, Darrick J. Wong wrote:
> > So your solution is to split the delalloc reservation to constrain the
> > allocation to the range that's being operated on?
> Yes, I'm trying to split delalloc reservation.
> > 
> > If so, I think a better solution (at least from the perspective of
> > reducing fragmentation) would be to map the extent unwritten and force a
> > post-writeback conversion[1] but I got shot down for performance reasons
> > the last time I suggested that.
> I'm wondering if spliting delalloc reservation have the same performance
> issue.

Probably not, but OTOH will doing so (a) have a noticeable effect on
fragmentation, and (b) will the kernel code choke on two adjacent
delalloc extents that could be merged?  (I think the answer is no since
we'll either complete the operation or the fs goes down...?)

--D

> Thanks!
> Yu Kuai
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ