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: <20191009142438.yx74ukfqwy2hr4fz@pathway.suse.cz>
Date:   Wed, 9 Oct 2019 16:24:38 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Qian Cai <cai@....pw>
Cc:     Michal Hocko <mhocko@...nel.org>,
        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>,
        PeterOberparleiter <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 2019-10-09 09:43:13, Qian Cai wrote:
> On Wed, 2019-10-09 at 15:27 +0200, Michal Hocko wrote:
> > 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.
> 
> An obvious one is in the above link. Just replace the trace in #1 above with
> printk() from anywhere, i.e., just ignore the early boot calls there as they are
>  not important.
> 
> printk()
>   console_unlock()
>     console_lock_spinning_enable() --> console_owner_lock
>   call_console_drivers()
>     serial8250_console_write() --> port->lock

Please, find the location where this really happens and then suggests
how the real deadlock could get fixed. So far, we have seen only
false positives and theoretical scenarios.

Best Regards,
Petr