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]

Message-ID: <87k4v6py3e.fsf@linux.vnet.ibm.com>
Date:	Mon, 25 Jan 2010 10:42:05 +0530
From:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	tytso@....edu
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 Sun, 24 Jan 2010 13:24:46 -0500, tytso@....edu wrote:
> 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.  :-)

My goal was to see if we can drop the BH_New flag when returning
preallocated blocks. But now i look at it again i guess you don't need
to take this patch. We cannot unmap underlying meta data during
fallocate because even if we remove the old mapping for the blocks,
we could reboot and later somebody(e2fsprogs) can directly read the blocks
and create a bh with old data. So i guess we should be doing
unmap_underlying_blocks when we are returning blocks to userspace or
when we actually zero out blocks.

-aneesh



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