e2fsck thinks that this:
# touch mnt/testfile1
# setfattr -n "user.test" mnt/testfile1
results in a filesystem with corruption:
Pass 1: Checking inodes, blocks, and sizes
Extended attribute in inode 12 has a value size (0) which is invalid
Clear? yes
but as far as I can tell, there is absolutely nothing wrong with
a 0-length value on an extended attribute. Just remove the check.
Reported-by: David Shaw <[email protected]>
Reported-by: Harald Reindl <[email protected]>
Addresses-Red-Hat-Bugzilla: #557959
Signed-off-by: Eric Sandeen <[email protected]>
---
Strange that this has been in e2fsck since 2005; apologies to
David in particular for not addressing the bug he filed much sooner,
I had assumed that this was some strange corruption, not a simple
logic error / change.
diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index a20b57b..94df36d 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -307,7 +307,7 @@ static void check_ea_in_inode(e2fsck_t ctx, struct problem_context *pctx)
remain -= EXT2_EXT_ATTR_SIZE(entry->e_name_len);
/* check value size */
- if (entry->e_value_size == 0 || entry->e_value_size > remain) {
+ if (entry->e_value_size > remain) {
pctx->num = entry->e_value_size;
problem = PR_1_ATTR_VALUE_SIZE;
goto fix;
On 4/7/13 1:42 PM, Eric Sandeen wrote:
> e2fsck thinks that this:
>
> # touch mnt/testfile1
> # setfattr -n "user.test" mnt/testfile1
>
> results in a filesystem with corruption:
>
> Pass 1: Checking inodes, blocks, and sizes
> Extended attribute in inode 12 has a value size (0) which is invalid
> Clear? yes
>
> but as far as I can tell, there is absolutely nothing wrong with
> a 0-length value on an extended attribute. Just remove the check.
>
> Reported-by: David Shaw <[email protected]>
> Reported-by: Harald Reindl <[email protected]>
> Addresses-Red-Hat-Bugzilla: #557959
> Signed-off-by: Eric Sandeen <[email protected]>
Ted, just a ping on this. I know there's been a lot going on,so
wasn't sure if you missed it, or if it's just saved for later.
Thanks,
-Eric
> ---
>
> Strange that this has been in e2fsck since 2005; apologies to
> David in particular for not addressing the bug he filed much sooner,
> I had assumed that this was some strange corruption, not a simple
> logic error / change.
>
> diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
> index a20b57b..94df36d 100644
> --- a/e2fsck/pass1.c
> +++ b/e2fsck/pass1.c
> @@ -307,7 +307,7 @@ static void check_ea_in_inode(e2fsck_t ctx, struct problem_context *pctx)
> remain -= EXT2_EXT_ATTR_SIZE(entry->e_name_len);
>
> /* check value size */
> - if (entry->e_value_size == 0 || entry->e_value_size > remain) {
> + if (entry->e_value_size > remain) {
> pctx->num = entry->e_value_size;
> problem = PR_1_ATTR_VALUE_SIZE;
> goto fix;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Sun, Apr 07, 2013 at 01:42:18PM -0500, Eric Sandeen wrote:
> e2fsck thinks that this:
>
> # touch mnt/testfile1
> # setfattr -n "user.test" mnt/testfile1
>
> results in a filesystem with corruption:
>
> Pass 1: Checking inodes, blocks, and sizes
> Extended attribute in inode 12 has a value size (0) which is invalid
> Clear? yes
>
> but as far as I can tell, there is absolutely nothing wrong with
> a 0-length value on an extended attribute. Just remove the check.
>
> Reported-by: David Shaw <[email protected]>
> Reported-by: Harald Reindl <[email protected]>
> Addresses-Red-Hat-Bugzilla: #557959
> Signed-off-by: Eric Sandeen <[email protected]>
Thanks, applied.
It turns out that 0-length values applied for xattrs stored in
external xattr blocks. 0-length xattrs were only only getting
prohibited for in-inode xattrs.
- Ted