All of lore.kernel.org
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 2/2] ext4: fix eofblock flag handling
Date: Tue, 25 May 2010 00:17:37 -0400	[thread overview]
Message-ID: <20100525041737.GB5556@thunk.org> (raw)
In-Reply-To: <1271687537-15655-2-git-send-email-dmonakhov@openvz.org>

On Mon, Apr 19, 2010 at 06:32:17PM +0400, Dmitry Monakhov wrote:
> - Fix NULL pointer deference on error path
> - Extent header we found may be not latest node of the inode. In order to
>   find latest extent we have to traverse a path from very beginning.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=15792
> 
> Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>

I split this patch into two patches, since they are addressing two
very distinct and different bugs.  As it turns out I chose a
completely different way of tackling the second issue, which has the
advantage being much simpler, and not requiring a second call to
ext4_ext_find_extent(), which can end up requiring extra disk reads.

Also note that I supplied a test case to demonstrate the problem.
This was helpful in assuring that the problem was fixed, and also in
proving that there really *was* a problem; as it turns out triggering
it is quite difficult and I would be very surprised if it has really
happenned in real life.

To construct the test case I first of all used a 1k block file system,
and then generated an extremely fragmented free space:

mkdir a; cd a
seq -f %05.0f 1 65536 | xargs touch
seq -f %05.0f 1 65536 | xargs -L 1 fallocate -l 1k
seq -f %05.0f 1 2 65536 | xargs rm
cd ..

I then created the fragmented file with the EOFBLOCKS set:

fallocate -n -l 32m foo

This should generate a file with a two-deep extent tree.  (It is
otherwise *very* hard to create a deep extent tree.)  I then found the
last block in an leaf block in the middle of the tree, and deleted the
last extent in that leaf block, using the tst_extents program found in
lib/ext2fs in the e2fsprogs sources (it is built using "make check").
In the case described in the commit, this happened to be for the
logical block 17925.

Could such a file be generated in real life?  Yes, but you'd have to
be quite unlucky, as it would require extending a sparse, fragmented
file using an i_size-preserving fallocate call, where there was a hole
at precisely the right (wrong) place in the extent tree.

			      	      	 - Ted

  reply	other threads:[~2010-05-25  4:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 14:32 [PATCH 1/2] ext4: Use bitops to read/modify EXT4_I(inode)->i_flags Dmitry Monakhov
2010-04-19 14:32 ` [PATCH 2/2] ext4: fix eofblock flag handling Dmitry Monakhov
2010-05-25  4:17   ` tytso [this message]
2010-05-25  4:18     ` [PATCH 1/2] ext4: Avoid crashing on NULL ptr dereference on a filesystem error Theodore Ts'o
2010-05-25  4:18     ` [PATCH 2/2] ext4: Clear the EXT4_EOFBLOCKS_FL flag only when warranted Theodore Ts'o
2010-05-25  7:23       ` Dmitry Monakhov
2010-05-25 13:03         ` tytso
2010-05-25 13:12           ` Dmitry Monakhov
2010-05-25 13:15             ` tytso
2010-05-25 13:19               ` Dmitry Monakhov
2010-05-24  3:09 ` [PATCH 1/2] ext4: Use bitops to read/modify EXT4_I(inode)->i_flags tytso
2010-05-24 20:49 ` [PATCH -v2] ext4: Use bitops to read/modify i_flags in struct ext4_inode_info Theodore Ts'o
2010-05-31  8:56   ` [PATCH] ext4: Use bitops to read/modify i_flags part2 Dmitry Monakhov
2010-06-01  3:06     ` tytso
2010-06-03  2:55     ` tytso
2010-06-03  8:48       ` Dmitry Monakhov
2010-06-03 10:37         ` Theodore Tso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100525041737.GB5556@thunk.org \
    --to=tytso@mit.edu \
    --cc=dmonakhov@openvz.org \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.