linux-ext4 - Re: ext4_ext_convert_to_initialized bug found in extended FSX testing

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 May 2011 09:47:23 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: ext4_ext_convert_to_initialized bug found in extended FSX testing

On Wed, May 11, 2011 at 1:56 AM, Allison Henderson
<achender@...ux.vnet.ibm.com> wrote:
> Hi All,
>
> We've been trying to get punch hole through some extended fsx tests, and I ran across some other tests that were failing because the test file contained zeros where it shouldn't.  I made this fix to the ext4_ext_convert_to_initialized

What do you mean zeros here?
Some useful data is zeroed?

and the test has been running smooth for about an hour now.
Yongqiang, this one looks like it may have been associated with the
split extents clean up patch.  Would you mind taking a look at this
fix and giving it your ok if it looks good?  Thx!
>
> Signed-off-by: Allison Henderson <achender@...ibm.com>
> ---
> :100644 100644 e363f21... ce69450... M  fs/ext4/extents.c
>  fs/ext4/extents.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index e363f21..ce69450 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -2819,7 +2819,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
>                        /* case 3 */
>                        zero_ex.ee_block =
>                                         cpu_to_le32(map->m_lblk + map->m_len);
> -                       zero_ex.ee_len = cpu_to_le16(allocated - map->m_len);
> +                       zero_ex.ee_len = cpu_to_le16(ee_len -
> +                                               allocated - map->m_len);
The logic is that we splits [ee_block, ee_block + ee_len) into
[ee_block, map->m_blk) that is uninitialized and [map->m_blk, ee_block
+ ee_len) that is initialized.   We need to zero [map->m_lblk +
map->m_len, ee_block + ee_len).
and [map->m_lblk, map->m_lblk + map->m_len) is zeroed by upper layer
because of MAP_NEW flag.

Right logic?


I can not see the error and the meaning of ee_len - allocated - map->m_len.

Thanks,
Yongqiang.


>                        ext4_ext_store_pblock(&zero_ex,
>                                ext4_ext_pblock(ex) + map->m_lblk - ee_block);
>                        err = ext4_ext_zeroout(inode, &zero_ex);
> --
> 1.7.1
>
>



-- 
Best Wishes
Yongqiang Yang
--
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