linux-ext4 - Re: e2fsprogs and blocks outside i

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:	Mon, 21 Jul 2008 11:29:18 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Andreas Dilger <adilger@....com>
Cc:	Theodore Tso <tytso@....edu>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: e2fsprogs and blocks outside i_size

On Sun, Jul 20, 2008 at 11:08:25PM -0600, Andreas Dilger wrote:
> On Jul 18, 2008  08:37 -0400, Theodore Ts'o wrote:
> > On Fri, Jul 18, 2008 at 05:41:30PM +0530, Aneesh Kumar K.V wrote:
> > > With fallocate FALLOC_FL_KEEP_SIZE option, when we write to prealloc
> > > space and if we hit ENOSPC when trying to insert the extent,
> > > we actually zero out the extent. That means we can have blocks
> > > outside i_size for an inode.
> 
> To clarify, doesn't FALLOC_FL_KEEP_SIZE put the extent beyond i_size,
> regardless of whether the ENOSPC problem is hit?

But the extent in that case would be marked as uninit using the extent
len. So e2fsck can check for that.


> 
> > > I guess e2fsck currently doesn't handle this. Or should we fix kernel
> > > to update i_size to the right value if we do a zero out of the extent ?
> > > 
> > > With fallocate if the prealloc area is small we also aggressively zeroout.
> > > This was needed so that a random write pattern on falloc area doesn't
> > > results in too many extents.  That also can result in the above
> > > error on fsck.
> > 
> > It would seem to me that e2fsck should be fixed to not complain about
> > blocks outside of i_size, *if* the blocks in question are marked as
> > being unitialized.
> 
> Yes, I think that is the right approach.



That is fine for extents marked uninit. But when we zero out we zero out
the full extent. So that means a write of few bytes can result in blocks
being zeroed out outside i_size.  My question was how e2fsck can handle
this. Because the extent will no more be marked as uninit and  there
would be blocks outside i_size all carrying zero. 


> 
> > I suppose the other hack we could do is have e2fsck check the blocks
> > that are outside of i_size, and if they are all zero and extents are
> > involved, that it's a case of pre-allocated blocks that needed to be
> > zero'ed for some reason, as opposed to a corrupted i_size.  That seems
> > to be a really gross hack, though.
> 
> Yuck, with the added problem that there is no guarantee that these
> data blocks ARE all zero.
> 

-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