linux-ext4 - Re: [REGRESSION] xfstests #269 without journal failure against 'dev' branch

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] [day] [month] [year] [list]

Message-ID: <20130222024452.GA3421@gmail.com>
Date:	Fri, 22 Feb 2013 10:44:52 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [REGRESSION] xfstests #269 without journal failure against 'dev'
 branch

On Thu, Feb 21, 2013 at 02:44:48PM -0500, Theodore Ts'o wrote:
> I was able to reproduce the failure reliably by using a 5G tmpfs file
> for the VM's disk file, and bisected this down to:
> 
>     ext4: support simple conversion of extent-mapped inodes to use i_blocks
>     
>     In order to make it simpler to test the code which support
>     i_blocks/indirect-mapped inodes, support the conversion of inodes
>     which are less than 12 blocks and which are contained in no more than
>     a single extent.
>     
>     The primary intended use of this code is to converting freshly created
>     zero-length files and empty directories.
>     
>     Note that the version of chattr in e2fsprogs 1.42.7 and earlier has a
>     check that prevents the clearing of the extent flag.  A simple patch
>     which allows "chattr -e <file>" to work will be checked into the
>     e2fsprogs git repository.
>     
>     Signed-off-by: "Theodore Ts'o" <tytso@....edu>
> 
> I don't think this is actually causing the problem, but rather
> exposing a latent bug in fs/ext4/indirect.c.  From some code
> inspection that I did investigating the resize2fs bug, it's pretty
> clear that indirect.c codepath has some bugs dealing with ENOSPC
> conditions when allocating indirect metadata blocks.
> 
> Xfstests #269 runs fsstress in parallel with ENOSPC hitters, and one
> of the things fsstress does is to call the FS_IOC_SETFLAGS with random
> values, so with this commit, we are migrating some small files to use
> indirect block..  I suspect that when we then do some writes to these
> small files and they hit an ENOSPC condition, it causes the file
> system corruption.
> 
> I patched ext4_ind_migrate() to log an ext4_warning and then return
> -ENOSPC, and confirmed that (a) with ext4_end_migrate() disabled, the
> fs corruption problem went away, and (b) fsstress is calling
> FS_IOC_SETFLAGS with completely random values, and thus causing us to
> migrate some of the extent-mapped files to indirect block mapped
> files.
> 
> Given that extents->indirect migration isn't really that important, I
> propose we deal with this by dropping the above commit for now.  It's
> clear we need to fix up fs/ext4/indirect.c, especially as more
> distro's consider using ext4 to support ext3 file systems.  So after
> we fix the ENOSPC bugs I've noticed in ext4_alloc_branch(), we can try
> introducing the extent->indirect migration feature again for the next
> merge window.
> 
> Zheng, thanks for calling this bug to our attention, and thanks for
> your extensive testing efforts!

Hi Ted,

Thanks for your explanation.  I agree with you that we could drop this
patch temporarily and take it back after we fix the ENOSPC bug in
ext4_alloc_branch().

Regards,
                                                - Zheng
--
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