Skip to contentSkip to conversation

e2fsprogs: fix ext2fs_extent_get for uninit leaf extents

PATCH In review Eric Sandeen 2 participants 3 messages Mar 19, 2008 – Mar 20, 2008

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 e2fsprogs: fix ext2fs_extent_get for uninit leaf extents

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.

---

lib/ext2fs/extent.c +2 -2
index ab211b1..c616984 100644
@@ -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) +
e2fsck/pass1.c +4 -2
index 50e38e1..79e9f23 100644
@@ -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;
#1 lore raw
Quoted 3 lines · Eric Sandeen

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

#2 lore raw
Quoted 5 lines · Theodore Tso
Quoted 3 lines · Eric Sandeen

Fix ext2fs_extent_get for uninit leaf extents

From: Eric Sandeen <[email protected]>

Quoted 7 lines

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

Quoted 28 lines

% 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