linux-ext4 - Re: i_size error with the latest patchqueue

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: <20080731164728.GF11632@mit.edu>
Date:	Thu, 31 Jul 2008 12:47:28 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	ext4 <linux-ext4@...r.kernel.org>
Subject: Re: i_size error with the latest patchqueue

On Thu, Jul 31, 2008 at 09:40:59PM +0530, Aneesh Kumar K.V wrote:
> Hi Ted,
> 
> I haven't yet looked at whether it is kernel or e2fsck bug.
> But I am having this with the latest patch queue when running
> fsstress. The fsstress have falloc added as a supported operation.
> So it is mostly to do with fallocate. Architecture is x86.

Part of this is definitely an e2fsck bug, because e2fsck isn't
currently checking the EXT2_EXTENT_FLAGS_UNINIT flag.  In line 1715 of
e2fsck/pass1.c:

	start_block = pb->last_block = extent.e_lblk + extent.e_len - 1;

We shouldn't be setting pb->last_block if this is an unitialized
extent.

I suspect this is also related though to the issue you raised in the
"e2fsprogs and blocks outside i_size" thread about two weeks ago.  So
even after we fix this e2fsck bug, we may still have some fsstress
failures until we decide how to deal with that particular issue.

Do you have a quickie program that calls fallocate to preallocate
space for a particular program easily to hand?  If not, I can write
one in about 5-10 minutes, but if you have one written already, it'll
save me the effort.  Thanks!!

						- 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