linux-kernel - Re: ext4: add kunit test for decoding extended timestamps

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-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdUoOWugmyAA3-dP=AAMYwLy7KPKpGzXwxRn_yTJugM+Ww@mail.gmail.com>
Date:   Tue, 26 Nov 2019 14:15:04 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Iurii Zaikin <yzaikin@...gle.com>
Cc:     Shuah Khan <skhan@...uxfoundation.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Theodore Tso <tytso@....edu>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>
Subject: Re: ext4: add kunit test for decoding extended timestamps

Hi Lurii,

On Tue, Nov 26, 2019 at 3:12 AM Linux Kernel Mailing List
<linux-kernel@...r.kernel.org> wrote:
> Commit:     1cbeab1b242d16fdb22dc3dab6a7d6afe746ae6d
> Parent:     d460623c5fa126dc51bb2571dd7714ca75b0116c
> Refname:    refs/heads/master
> Web:        https://git.kernel.org/torvalds/c/1cbeab1b242d16fdb22dc3dab6a7d6afe746ae6d
> Author:     Iurii Zaikin <yzaikin@...gle.com>
> AuthorDate: Thu Oct 17 15:12:33 2019 -0700
> Committer:  Shuah Khan <skhan@...uxfoundation.org>
> CommitDate: Wed Oct 23 10:28:23 2019 -0600
>
>     ext4: add kunit test for decoding extended timestamps
>
>     KUnit tests for decoding extended 64 bit timestamps that verify the
>     seconds part of [a/c/m] timestamps in ext4 inode structs are decoded
>     correctly.
>
>     Test data is derived from the table in the Inode Timestamps section of
>     Documentation/filesystems/ext4/inodes.rst.
>
>     KUnit tests run during boot and output the results to the debug log
>     in TAP format (http://testanything.org/). Only useful for kernel devs
>     running KUnit test harness and are not for inclusion into a production
>     build.
>
>     Signed-off-by: Iurii Zaikin <yzaikin@...gle.com>
>     Reviewed-by: Theodore Ts'o <tytso@....edu>
>     Reviewed-by: Brendan Higgins <brendanhiggins@...gle.com>
>     Tested-by: Brendan Higgins <brendanhiggins@...gle.com>
>     Reviewed-by: Shuah Khan <skhan@...uxfoundation.org>
>     Signed-off-by: Shuah Khan <skhan@...uxfoundation.org>

While this test succeeds on arm64, it fails on m68k and arm32 (presumably
all 32-bit platforms?):

# Subtest: ext4_inode_test
1..1
# inode_test_xtimestamp_decoding: EXPECTATION FAILED at fs/ext4/inode-test.c:250
Expected test_data[i].expected.tv_sec == timestamp.tv_sec, but
test_data[i].expected.tv_sec == -2147483648
timestamp.tv_sec == 2147483648
1901-12-13 Lower bound of 32bit < 0 timestamp, no extra bits: msb:1
lower_bound:1 extra_bits: 0
# inode_test_xtimestamp_decoding: EXPECTATION FAILED at fs/ext4/inode-test.c:250
Expected test_data[i].expected.tv_sec == timestamp.tv_sec, but
test_data[i].expected.tv_sec == 2147483648
timestamp.tv_sec == 6442450944
2038-01-19 Lower bound of 32bit <0 timestamp, lo extra sec bit on:
msb:1 lower_bound:1 extra_bits: 1
# inode_test_xtimestamp_decoding: EXPECTATION FAILED at fs/ext4/inode-test.c:250
Expected test_data[i].expected.tv_sec == timestamp.tv_sec, but
test_data[i].expected.tv_sec == 6442450944
timestamp.tv_sec == 10737418240
2174-02-25 Lower bound of 32bit <0 timestamp, hi extra sec bit on:
msb:1 lower_bound:1 extra_bits: 2
not ok 1 - inode_test_xtimestamp_decoding
not ok 1 - ext4_inode_test

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds