Fix ext2fs_extent_get for uninit leaf extents
From: Eric Sandeen <[email protected]>
The ext2fs_extent_get() function was not OR-ing together UNINIT
and LEAF flags in the case where an extent was both; so if we
had an extent which was both uniint and leaf, pass1 would bail
out where depth == max_depth but was not marked as leaf, and
e2fsck (from the next branch) would abort with:
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Error1: No 'down' extent
Aborted
Also, if the error is encountered again, print the inode number
to aid debugging until it's properly handled, at least.
Signed-off-by: Eric Sandeen <[email protected]>
---
diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
index ab211b1..c616984 100644
--- a/lib/ext2fs/extent.c
+++ b/lib/ext2fs/extent.c
@@ -463,10 +463,10 @@ retry:
((__u64) ext2fs_le16_to_cpu(ex->ee_start_hi) << 32);
extent->e_lblk = ext2fs_le32_to_cpu(ex->ee_block);
extent->e_len = ext2fs_le16_to_cpu(ex->ee_len);
- extent->e_flags = EXT2_EXTENT_FLAGS_LEAF;
+ extent->e_flags |= EXT2_EXTENT_FLAGS_LEAF;
if (extent->e_len > EXT_INIT_MAX_LEN) {
extent->e_len -= EXT_INIT_MAX_LEN;
- extent->e_flags = EXT2_EXTENT_FLAGS_UNINIT;
+ extent->e_flags |= EXT2_EXTENT_FLAGS_UNINIT;
}
} else {
extent->e_pblk = ext2fs_le32_to_cpu(ix->ei_leaf) +
diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 50e38e1..79e9f23 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -1622,14 +1622,16 @@ static void scan_extent_node(e2fsck_t ctx, struct problem_context *pctx,
pctx->errcode = ext2fs_extent_get(ehandle,
EXT2_EXTENT_DOWN, &extent);
if (pctx->errcode) {
- printf("Error1: %s\n", error_message(pctx->errcode));
+ printf("Error1: %s on inode %lld\n",
+ error_message(pctx->errcode), pctx->ino);
abort();
}
scan_extent_node(ctx, pctx, pb, ehandle);
pctx->errcode = ext2fs_extent_get(ehandle,
EXT2_EXTENT_UP, &extent);
if (pctx->errcode) {
- printf("Error1: %s\n", error_message(pctx->errcode));
+ printf("Error1: %s on inode %lld\n",
+ error_message(pctx->errcode), pctx->ino);
abort();
}
goto next;
On Wed, Mar 19, 2008 at 03:20:18PM -0500, Eric Sandeen wrote:
> Fix ext2fs_extent_get for uninit leaf extents
>
> From: Eric Sandeen <[email protected]>
I'm guessing you used git-format-patch but not git-send-mail to send
out the patch? Not a big deal, but it meant I had to do a "git commit
--amend" to edit out the aboe two lines after doing a "git am".
Suggested workflow that results in a nice patch series being sent to
linux-ext4, as well as making it easy for a maintainer using git to
suck it into git:
% git-format-patch -n --subject-prefix="PATCH, E2FSPROGS" -o /tmp/to-send master
This creates the patch series for all commits starting at the
branch master (substitute next if you are basing your
development branch off of next, etc.), and places the results
in the directory /tmp/to-send, which will be created if it
doesn't exist. It will use the first line of the commit log
as the subject line, prefixed with [I/N PATCH, E2FSPROGS],
where I/N will be 1/10, 2/10, 3/10, etc. "Git am" will take
the subject, strip out what is in square brackets and use that
as the first line of the commit log.
% git-send-email [email protected] /tmp/to-send
This will send the patches found in /tmp/to-send to
[email protected], appropritaely formated. If you
want to add an introductory message, add the option --compose
to the above command-line. If you want to make the patch
series be a reply to some message thread, just note the
Message-ID of the message you want to reply to, and just copy
and paste it into git-send-email when it prompts you to do so.
If you want the patch series to start a new thread, just hit
return when the program prompts you for a In-Reply-To message-ID.
Anyway, I've applied the patch and it's in the e2fsprogs tree. Thanks
for noticing it!
- Ted
Theodore Tso wrote:
> On Wed, Mar 19, 2008 at 03:20:18PM -0500, Eric Sandeen wrote:
>> Fix ext2fs_extent_get for uninit leaf extents
>>
>> From: Eric Sandeen <[email protected]>
>
> I'm guessing you used git-format-patch but not git-send-mail to send
> out the patch? Not a big deal, but it meant I had to do a "git commit
> --amend" to edit out the aboe two lines after doing a "git am".
>
> Suggested workflow that results in a nice patch series being sent to
> linux-ext4, as well as making it easy for a maintainer using git to
> suck it into git:
Thanks... I'm still embarassingly git-illiterate. Will do better next
time :)
-Eric
> % git-format-patch -n --subject-prefix="PATCH, E2FSPROGS" -o /tmp/to-send master
>
> This creates the patch series for all commits starting at the
> branch master (substitute next if you are basing your
> development branch off of next, etc.), and places the results
> in the directory /tmp/to-send, which will be created if it
> doesn't exist. It will use the first line of the commit log
> as the subject line, prefixed with [I/N PATCH, E2FSPROGS],
> where I/N will be 1/10, 2/10, 3/10, etc. "Git am" will take
> the subject, strip out what is in square brackets and use that
> as the first line of the commit log.
>
> % git-send-email [email protected] /tmp/to-send
>
> This will send the patches found in /tmp/to-send to
> [email protected], appropritaely formated. If you
> want to add an introductory message, add the option --compose
> to the above command-line. If you want to make the patch
> series be a reply to some message thread, just note the
> Message-ID of the message you want to reply to, and just copy
> and paste it into git-send-email when it prompts you to do so.
> If you want the patch series to start a new thread, just hit
> return when the program prompts you for a In-Reply-To message-ID.
>
> Anyway, I've applied the patch and it's in the e2fsprogs tree. Thanks
> for noticing it!
>
> - Ted