linux-kernel - Re: [BUG] rockpro64 board hangs in console

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]

Message-ID: <Yqf3pxG16lQcacUA@google.com>
Date:   Tue, 14 Jun 2022 11:51:19 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     Alexandru Elisei <alexandru.elisei@....com>
Cc:     sunjunchao2870@...il.com, jack@...e.cz, viro@...iv.linux.org.uk,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        pmladek@...e.com, senozhatsky@...omium.org, rostedt@...dmis.org,
        john.ogness@...utronix.de, keescook@...omium.org, anton@...msg.org,
        ccross@...roid.com, tony.luck@...el.com, heiko@...ech.de,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, maco@...roid.com, hch@....de,
        gregkh@...uxfoundation.org, jirislaby@...nel.org
Subject: Re: [BUG] rockpro64 board hangs in console_init() after commit
 10e14073107d

On (22/06/13 17:54), Alexandru Elisei wrote:
[..]
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
> [    0.000001] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
> [    0.005107] Console: colour dummy device 80x25
> [    0.005549] printk: console [tty0] enabled
> [    0.005956] printk: bootconsole [uart0] disabled
> 
> Config can be found at [1] (expires after 6 months). I've also built the
> kernel with gcc 10.3.1 [2] (aarch64-none-linux-gnu), same issue.
> 
> I've bisected the build failure to commit 10e14073107d ("writeback: Fix
> inode->i_io_list not be protected by inode->i_lock error"); I've confirmed
> that that commit is responsible by successfully booting the board with a
> kernel built from v5.19-rc2 + the above commit reverted.

Hmm, interesting and puzzling.

If you disable console kthreads (__printk_fallback_preferred_direct) and
keep 10e14073107d, are you able to successfully boot the board or does it
boot to a panic?

> I tried to do some investigating, it seems that the kernel is stuck at
> printk.c::console_init() -> drivers/tty/vt/vt.c::con_init() ->
> printk.c::register_console() -> unregister_console() -> console_lock().

Is it console lock (console_kthreads_block() -> mutex_lock(&con->lock))
that we cannot grab or is it console semaphore?