From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5584C47404 for ; Wed, 9 Oct 2019 14:24:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8E3BF20B7C for ; Wed, 9 Oct 2019 14:24:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731386AbfJIOYl (ORCPT ); Wed, 9 Oct 2019 10:24:41 -0400 Received: from mx2.suse.de ([195.135.220.15]:54988 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729491AbfJIOYl (ORCPT ); Wed, 9 Oct 2019 10:24:41 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7BEAEAD2C; Wed, 9 Oct 2019 14:24:39 +0000 (UTC) Date: Wed, 9 Oct 2019 16:24:38 +0200 From: Petr Mladek To: Qian Cai Cc: Michal Hocko , Christian Borntraeger , Heiko Carstens , 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 , PeterOberparleiter , david@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk() Message-ID: <20191009142438.yx74ukfqwy2hr4fz@pathway.suse.cz> References: <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> <20191009132746.GA6681@dhcp22.suse.cz> <1570628593.5937.3.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: <1570628593.5937.3.camel@lca.pw> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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