linux-kernel - Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk()

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: <20191009132746.GA6681@dhcp22.suse.cz>
Date:   Wed, 9 Oct 2019 15:27:46 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Qian Cai <cai@....pw>
Cc:     Petr Mladek <pmladek@...e.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        sergey.senozhatsky.work@...il.com, rostedt@...dmis.org,
        peterz@...radead.org, linux-mm@...ck.org,
        john.ogness@...utronix.de, akpm@...ux-foundation.org,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Peter Oberparleiter <oberpar@...ux.ibm.com>, david@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk()

On Wed 09-10-19 09:06:42, Qian Cai wrote:
[...]
> https://lore.kernel.org/linux-mm/1570460350.5576.290.camel@lca.pw/
> 
> [  297.425964] -> #1 (&port_lock_key){-.-.}:
> [  297.425967]        __lock_acquire+0x5b3/0xb40
> [  297.425967]        lock_acquire+0x126/0x280
> [  297.425968]        _raw_spin_lock_irqsave+0x3a/0x50
> [  297.425969]        serial8250_console_write+0x3e4/0x450
> [  297.425970]        univ8250_console_write+0x4b/0x60
> [  297.425970]        console_unlock+0x501/0x750
> [  297.425971]        vprintk_emit+0x10d/0x340
> [  297.425972]        vprintk_default+0x1f/0x30
> [  297.425972]        vprintk_func+0x44/0xd4
> [  297.425973]        printk+0x9f/0xc5
> [  297.425974]        register_console+0x39c/0x520
> [  297.425975]        univ8250_console_init+0x23/0x2d
> [  297.425975]        console_init+0x338/0x4cd
> [  297.425976]        start_kernel+0x534/0x724
> [  297.425977]        x86_64_start_reservations+0x24/0x26
> [  297.425977]        x86_64_start_kernel+0xf4/0xfb
> [  297.425978]        secondary_startup_64+0xb6/0xc0
> 
> where the report again show the early boot call trace for the locking
> dependency,
> 
> console_owner --> port_lock_key
> 
> but that dependency clearly not only happen in the early boot.

Can you provide an example of the runtime dependency without any early
boot artifacts? Because this discussion really doens't make much sense
without a clear example of a _real_ lockdep report that is not a false
possitive. All of them so far have been concluded to be false possitive
AFAIU.
-- 
Michal Hocko
SUSE Labs