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

>>>>> Amit K Arora (AKA) writes:

 AT> I'm also not sure we need ext4_ext_find_extent() here.
 AKA> Do you mean ext4_ext_next_allocated_block() above ? We anyhow have to
 AKA> call find_extent() to get the possible neighbouring extent.

no, I exactly meant ext4_ext_find_extent(). it's expensive
compared to ext4_ext_next_allocated_block().
and if I understand right, you don't need whole extent, you
just need to know next allocated block, which can be retrieved
from index even. this is what ext4_ext_next_allocated_block() does.

 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.

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

existing blocks are to be handled properly in get_blocks():

	/* if found extent covers block, simply return it */
        if (iblock >= ee_block && iblock < ee_block + ee_len) {
		newblock = iblock - ee_block + ee_start;
		/* number of remaining blocks in the extent */
		allocated = ee_len - (iblock - ee_block);
		ext_debug("%d fit into %lu:%d -> %llu\n", (int) iblock,
				ee_block, ee_len, newblock);
		ext4_ext_put_in_cache(inode, ee_block, ee_len,
				      ee_start, EXT4_EXT_CACHE_EXTENT);

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

my pleasure.

thanks, Alex
-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ