linux-ext4 - Re: xfstest-bld generic/018 fails due to e4defrag issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Apr 2014 00:13:49 -0400
From:	jon ernst <jonernst07@...il.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	"linux-ext4@...r.kernel.org List" <linux-ext4@...r.kernel.org>
Subject: Re: xfstest-bld generic/018 fails due to e4defrag issue

On Wed, Apr 9, 2014 at 6:03 PM, Theodore Ts'o <tytso@....edu> wrote:
> On Wed, Apr 09, 2014 at 01:37:04AM -0400, jon ernst wrote:
>> running latest xfstest-bld with latest ext4 kernel "dev"
>> branch(ad6599ab3a).I always get generic/018 failed.
>> Then I took closer look and found out this issue.
>
> That's a renamed tested; it was previously shared/218.  It's a test
> which is known to fail for ext4, since its idea of how a defrag
> program should work is slightly different from how e4defrag works:
>
> shared/218 7s ...   [20:48:32] [20:48:39] - output mismatch (see /results/results-4k/shared/218.out.bad)
>     --- tests/shared/218.out   2014-04-01 18:46:39.000000000 +0000
>     +++ /results/results-4k/shared/218.out.bad               2014-04-03 20:48:39.795694518 +0000
>     @@ -10,7 +10,7 @@
>      After: 1
>      Write backwards sync, but contiguous - should defrag to 1 extent
>      Before: 10
>     -After: 1
>     +After: 10
>      Write backwards sync leaving holes - defrag should do nothing
>      Before: 16
>     ...
>     (Run 'diff -u tests/shared/218.out /results/results-4k/shared/218.out.bad'  to see the entire diff)
>
> What you are seeing is something very different, though.
>
>> Even though the file does exist. e4defrag complains about:
>>
>> (this output comes from kvm guest machine)
>> > e4defrag -v /vdf/testfile
>> Can't get super block info: Success
>> "/vdf/testfile"
>>
>> Is this a known issue or something I did wrong.
>
> Unfortunately, e4defrag has horrible error handling, so we can't see
> the error code properly, so we can't see why it's failing, but this is
> from an attempt to open the file system to get some low-level
> information.
>
> How is /etc/mtab set up on your test machine?  It looks like it failed
> to find block device for the file system in question.
>
>                                          - Ted

I found the root cause of this failure.

The failure case happens on "bigalloc" testing option.
ext2fs_open failed due to EXT2_FLAG_64BITS is not being set in testing
rootfs image. So ext2fs_open in e4defrag.c returns err: 2133571465.

Because bigalloc requires cluster-aware bitfield operations, which
means we need EXT2_FLAG_64BITS.
I see e2image.c creates image always with EXT2_FLAG_64BITS flag. It is
safe to do same thing for e4defrag in my opinion. Please correct me if
I am wrong.




[PATCH] e4defrag: open fs with EXT2_FLAG_64BITS flag

Signed-off-by: Jon Ernst <jonernst07@...il.com>
---
 misc/e4defrag.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/misc/e4defrag.c b/misc/e4defrag.c
index 620f4e7..c5a2754 100644
--- a/misc/e4defrag.c
+++ b/misc/e4defrag.c
@@ -1794,7 +1794,7 @@ int main(int argc, char *argv[])

                if (current_uid == ROOT_UID) {
                        /* Get super block info */
-                       ret = ext2fs_open(dev_name, 0, 0, block_size,
+                       ret = ext2fs_open(dev_name,EXT2_FLAG_64BITS,
0, block_size,
                                        unix_io_manager, &fs);
                        if (ret) {
                                if (mode_flag & DETAIL) {
-- 
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html