linux-ext4 - Re: [PATCH 1/1 version2] Extent overlap bugfix in ext4

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:	Thu, 4 Jan 2007 16:57:07 +0530
From:	"Amit K. Arora" <aarora@...ux.vnet.ibm.com>
To:	Alex Tomas <alex@...sterfs.com>
Cc:	Mingming Cao <cmm@...ibm.com>, linux-ext4@...r.kernel.org,
	suparna@...ibm.com
Subject: Re: [PATCH 1/1 version2] Extent overlap bugfix in ext4

On Thu, Jan 04, 2007 at 01:39:24PM +0300, Alex Tomas (AT) wrote:
> >>>>> Amit K Arora (AKA) writes:
> 
>  AKA> +int ext4_ext_check_overlap(struct inode *inode,
>  AKA> +					struct ext4_extent *newext,
>  AKA> +					unsigned long *block)
>  AKA> +{
>  AKA> +	struct ext4_ext_path *path;
>  AKA> +	unsigned int depth, b1, len1;
>  AKA> +	int ret = 0;
>  AKA> +
>  AKA> +	b1 = le32_to_cpu(newext->ee_block);
>  AKA> +	len1 = le16_to_cpu(newext->ee_len);
>  AKA> +	path = ext4_ext_find_extent(inode, b1, NULL);
>  AKA> +	if (IS_ERR(path)) {
>  AKA> +		ret = PTR_ERR(path);
>  AKA> +		goto out;
>  AKA> +	}
>  AKA> +	depth = ext_depth(inode);
>  AKA> +	BUG_ON(path[depth].p_ext == NULL && depth != 0);
>  AKA> +
>  AKA> +	*block = ext4_ext_next_allocated_block(path);
>  AKA> +	if (*block == EXT_MAX_BLOCK)
>  AKA> +		goto out;
>  AKA> +
>  AKA> +	if (b1 + len1 > *block)
>  AKA> +		ret = 1;
>  AKA> +out:
>  AKA> +	return ret;
>  AKA> +}
 
> AT> I'm also not sure we need ext4_ext_find_extent() here.
Do you mean ext4_ext_next_allocated_block() above ? We anyhow have to
call find_extent() to get the possible neighbouring extent.

> AT> there are two possibilities:
> 
> AT> 1) extent in found path covers block(s) before requested ones
> AT>    then ext4_ext_next_allocated_block(path) can be used
> 
> AT> 2) extent in found path covers block(s) after request ones
> AT>    then ee_block from that extent can be used.

You are right. In the case the requested block(s) lie within a hole, when
this hole starts from the begining of the file, this will be true. i.e.,
find_blocks() will return the extent after the requested block(s). In all
other cases, it will return the extent before the requested block(s)
(assuming there is no existing extent which covers the start of the
requested blocks).

Will change the code accordingly to handle this corner case. Thanks for
pointing this out !

--
Regards,
Amit Arora
-
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