linux-ext4 - Re: [PATCH -V2] ext4: unmap the underlying metadata when allocating blocks via fallocate

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:	Sun, 24 Jan 2010 13:24:46 -0500
From:	tytso@....edu
To:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	Eric Sandeen <sandeen@...hat.com>, cmm@...ibm.com,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH -V2] ext4: unmap the underlying metadata when
 allocating blocks via fallocate

On Fri, Jan 15, 2010 at 12:00:58AM +0530, Aneesh Kumar K. V wrote:
> From 947ca1e49381bd76b85b44a1d41336a105e421ad Mon Sep 17 00:00:00 2001
> From: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
> Date: Thu, 7 Jan 2010 00:48:12 +0530
> Subject: [PATCH] ext4: unmap the underlying metadata when allocating blocks via fallocate
> 
> This become important when we are running with nojournal mode. We
> may end up allocating recently freed metablocks for fallocate. We
> want to make sure we unmap the old mapping so that when we convert
> the fallocated uninitialized extent to initialized extent we don't
> have the old mapping around. Leaving the old mapping can cause
> file system corruption
> 
> Now that we unmap old metadata blocks we need not return blocks
> allocated from fallocate area as new.

Is this patch still strictly necessary given commit 515f41c?  This
clears the blocks when we convert the extent from uninitialized to
initialized.   

Hmmm, or is the problem that this fixes the problem only for the
zero'ed out blocks, but we can still get burned on the write path?  
No, we fix that up in mpage_da_map_blocks.

So do we need this patch?  It seems more efficient to clear it when we
actually write or zero out the blocks; I thought that was the
conclusion we came to when we were discussing curtw's patch (515f41c
above).

If we now decide that we need call unmap_underlying_blocks() at
fallocate time, maybe we should revert 515f41c?  No point doing the
work twice; we probably have better uses for the CPU.  :-)

     	       		     	    	     	  - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html