The ext4_ext_get_blocks() and ext4_ext_insert_extent() routines do not
check for extent overlap, when a new extent needs to be inserted in an
inode. An overlap is possible when the new extent being inserted has
ee_block that is not part of any of the existing extents, but the
tail/center portion
Amit K Arora (AKA) writes:
AKA The ext4_ext_get_blocks() and ext4_ext_insert_extent() routines do not
AKA check for extent overlap, when a new extent needs to be inserted in an
AKA inode. An overlap is possible when the new extent being inserted has
AKA ee_block that is not part of any of
On Tue, Jan 02, 2007 at 12:25:21PM +0300, Alex Tomas (AT) wrote:
Amit K Arora (AKA) writes:
AKA The ext4_ext_get_blocks() and ext4_ext_insert_extent() routines do not
AKA check for extent overlap, when a new extent needs to be inserted in an
AKA inode. An overlap is possible when the new
Hi Mingming,
On Wed, Dec 27, 2006 at 03:30:44PM -0800, Mingming Cao wrote:
looks good to me, a few comments :)
Thanks for your comments!
.
+ ret = ext4_ext_get_blocks(handle, inode, block,
+ max_blocks, map_bh,
+
On Tue, 2007-01-02 at 16:34 +0530, Amit K. Arora wrote:
Hi Mingming,
And, Looking at other places calling ext4_*_get_blocks() in the kernel,
it seems not all of them protected by i_mutex lock. I think it probably
okay to not holding i_mutex during calling ext4_ext4_get_blocks().
We are
On Tue, 2007-01-02 at 14:39 +0530, Amit K. Arora wrote:
This problem was first sighted while stress testing (using modified
fsx-linux stress test) persistent preallocation patches that I posted
earlier. Though I am not able to reproduce this bug (extent overlap)
without the persistent
On Tue, Jan 02, 2007 at 05:35:28PM -0800, Mingming Cao wrote:
+struct ext4_extent * ext4_ext_check_overlap(struct inode *inode,
+ struct ext4_extent *newext)
+{
+ struct ext4_ext_path *path;
+ struct ext4_extent *ex;
+ unsigned int depth, b1, b2,
