Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 9 Oct 2019 15:27:46 +0200
From:   Michal Hocko <mhocko@kernel.org>
To:     Qian Cai <cai@lca.pw>
Cc:     Petr Mladek <pmladek@suse.com>,
        Christian Borntraeger <borntraeger@de.ibm.com>,
        Heiko Carstens <heiko.carstens@de.ibm.com>,
        sergey.senozhatsky.work@gmail.com, rostedt@goodmis.org,
        peterz@infradead.org, linux-mm@kvack.org,
        john.ogness@linutronix.de, akpm@linux-foundation.org,
        Vasily Gorbik <gor@linux.ibm.com>,
        Peter Oberparleiter <oberpar@linux.ibm.com>, david@redhat.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk()
Message-ID: <20191009132746.GA6681@dhcp22.suse.cz>
References: <20191008074357.f33f6pbs4cw5majk@pathway.suse.cz>
 <20191008082752.GB6681@dhcp22.suse.cz>
 <aefe7f75-b0ec-9e99-a77e-87324edb24e0@de.ibm.com>
 <1570550917.5576.303.camel@lca.pw>
 <20191008183525.GQ6681@dhcp22.suse.cz>
 <1570561573.5576.307.camel@lca.pw>
 <20191008191728.GS6681@dhcp22.suse.cz>
 <1570563324.5576.309.camel@lca.pw>
 <20191009114903.aa6j6sa56z2cssom@pathway.suse.cz>
 <1570626402.5937.1.camel@lca.pw>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1570626402.5937.1.camel@lca.pw>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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