linux-kernel - Re: 942437c97f ("y2038: allow disabling time32 system calls"): BUG: kernel hang in test stage

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

Message-ID: <CAK8P3a2rFb6RykcL3=4djkPgza=yi9hZE8w-Bu4-zUn5W9Pgvg@mail.gmail.com>
Date:   Sun, 1 Dec 2019 17:44:28 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     kernel test robot <lkp@...el.com>
Cc:     LKP <lkp@...ts.01.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 942437c97f ("y2038: allow disabling time32 system calls"): BUG:
 kernel hang in test stage

On Sun, Dec 1, 2019 at 4:11 PM kernel test robot <lkp@...el.com> wrote:
>
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
> commit 942437c97fd9ff23a17c13118f50bd0490f6868c
> Author:     Arnd Bergmann <arnd@...db.de>
> AuthorDate: Mon Jul 15 11:46:10 2019 +0200
> Commit:     Arnd Bergmann <arnd@...db.de>
> CommitDate: Fri Nov 15 14:38:30 2019 +0100
>
>     y2038: allow disabling time32 system calls
>
>     At the moment, the compilation of the old time32 system calls depends
>     purely on the architecture. As systems with new libc based on 64-bit
>     time_t are getting deployed, even architectures that previously supported
>     these (notably x86-32 and arm32 but also many others) no longer depend on
>     them, and removing them from a kernel image results in a smaller kernel
>     binary, the same way we can leave out many other optional system calls.
>
>     More importantly, on an embedded system that needs to keep working
>     beyond year 2038, any user space program calling these system calls
>     is likely a bug, so removing them from the kernel image does provide
>     an extra debugging help for finding broken applications.
>
>     I've gone back and forth on hiding this option unless CONFIG_EXPERT
>     is set. This version leaves it visible based on the logic that
>     eventually it will be turned off indefinitely.
>
>     Acked-by: Christian Brauner <christian.brauner@...ntu.com>
>     Signed-off-by: Arnd Bergmann <arnd@...db.de>
>
> bd40a17576  y2038: itimer: change implementation to timespec64
> 942437c97f  y2038: allow disabling time32 system calls
> +-----------------------------------------------------------+------------+------------+
> |                                                           | bd40a17576 | 942437c97f |
> +-----------------------------------------------------------+------------+------------+
> | boot_successes                                            | 38         | 0          |
> | boot_failures                                             | 0          | 19         |
> | BUG:kernel_hang_in_test_stage                             | 0          | 15         |
> | Assertion_failed                                          | 0          | 4          |
> | Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 0          | 4          |
> +-----------------------------------------------------------+------------+------------+
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot <lkp@...el.com>
>
> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> [    3.739930] rm (184) used greatest stack depth: 6556 bytes left
> [    5.754828] mount_root: mounting /dev/root
> [    5.762906] urandom-seed: Seed file not found (/etc/urandom.seed)
> [    5.767017] sh (172) used greatest stack depth: 6308 bytes left
> BUG: kernel hang in test stage

Thanks a lot for the report. As far as I can tell from the attached files, this
is a randconfig test on a 32-bit platform with
CONFIG_COMPAT_32BIT_TIME disabled, so this is expected
to fail because the existing user space application actually requires
the old system calls until it has been recompiled against a new
C library using 64-bit time_t.

We could probably make the failure more explicit and print an error
message for these particular syscalls when they are disabled.
Alternatively the configuration step would need to be changed that
the 0day bot is unable to run into this case.

      Arnd