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.5 required=3.0 tests=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 3D080ECE58E for ; Mon, 7 Oct 2019 15:12:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0C4E621721 for ; Mon, 7 Oct 2019 15:12:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0C4E621721 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 987078E0005; Mon, 7 Oct 2019 11:12:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 937458E0003; Mon, 7 Oct 2019 11:12:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84C758E0005; Mon, 7 Oct 2019 11:12:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 5D0EA8E0003 for ; Mon, 7 Oct 2019 11:12:40 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id E051F824CA0A for ; Mon, 7 Oct 2019 15:12:39 +0000 (UTC) X-FDA: 76017330438.12.meal28_173833a6ab543 X-HE-Tag: meal28_173833a6ab543 X-Filterd-Recvd-Size: 3095 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Oct 2019 15:12:39 +0000 (UTC) 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 38C55AC26; Mon, 7 Oct 2019 15:12:38 +0000 (UTC) Date: Mon, 7 Oct 2019 17:12:37 +0200 From: Michal Hocko To: Qian Cai Cc: Petr Mladek , akpm@linux-foundation.org, sergey.senozhatsky.work@gmail.com, rostedt@goodmis.org, peterz@infradead.org, linux-mm@kvack.org, john.ogness@linutronix.de, david@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk() Message-ID: <20191007151237.GP2381@dhcp22.suse.cz> References: <1570228005-24979-1-git-send-email-cai@lca.pw> <20191007143002.l37bt2lzqtnqjqxu@pathway.suse.cz> <1570460350.5576.290.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1570460350.5576.290.camel@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000569, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 07-10-19 10:59:10, Qian Cai wrote: [...] > It is almost impossible to eliminate all the indirect call chains from > console_sem/console_owner_lock to zone->lock because it is too normal t= hat > something later needs to allocate some memory dynamically, so as long a= s it > directly call printk() with zone->lock held, it will be in trouble. Do you have any example where the console driver really _has_ to allocate. Because I have hard time to believe this is going to work at all as the atomic context doesn't allow to do any memory reclaim and such an allocation would be too easy to fail so the allocation cannot really rely on it. So again, crippling the MM code just because of lockdep false possitives or a broken console driver sounds like a wrong way to approach the problem. > [=A0=A0297.425964] -> #1 (&port_lock_key){-.-.}: > [=A0=A0297.425967]=A0=A0=A0=A0=A0=A0=A0=A0__lock_acquire+0x5b3/0xb40 > [=A0=A0297.425967]=A0=A0=A0=A0=A0=A0=A0=A0lock_acquire+0x126/0x280 > [=A0=A0297.425968]=A0=A0=A0=A0=A0=A0=A0=A0_raw_spin_lock_irqsave+0x3a/0= x50 > [=A0=A0297.425969]=A0=A0=A0=A0=A0=A0=A0=A0serial8250_console_write+0x3e= 4/0x450 > [=A0=A0297.425970]=A0=A0=A0=A0=A0=A0=A0=A0univ8250_console_write+0x4b/0= x60 > [=A0=A0297.425970]=A0=A0=A0=A0=A0=A0=A0=A0console_unlock+0x501/0x750 > [=A0=A0297.425971]=A0=A0=A0=A0=A0=A0=A0=A0vprintk_emit+0x10d/0x340 > [=A0=A0297.425972]=A0=A0=A0=A0=A0=A0=A0=A0vprintk_default+0x1f/0x30 > [=A0=A0297.425972]=A0=A0=A0=A0=A0=A0=A0=A0vprintk_func+0x44/0xd4 > [=A0=A0297.425973]=A0=A0=A0=A0=A0=A0=A0=A0printk+0x9f/0xc5 > [=A0=A0297.425974]=A0=A0=A0=A0=A0=A0=A0=A0register_console+0x39c/0x520 > [=A0=A0297.425975]=A0=A0=A0=A0=A0=A0=A0=A0univ8250_console_init+0x23/0x= 2d > [=A0=A0297.425975]=A0=A0=A0=A0=A0=A0=A0=A0console_init+0x338/0x4cd > [=A0=A0297.425976]=A0=A0=A0=A0=A0=A0=A0=A0start_kernel+0x534/0x724 > [=A0=A0297.425977]=A0=A0=A0=A0=A0=A0=A0=A0x86_64_start_reservations+0x2= 4/0x26 > [=A0=A0297.425977]=A0=A0=A0=A0=A0=A0=A0=A0x86_64_start_kernel+0xf4/0xfb > [=A0=A0297.425978]=A0=A0=A0=A0=A0=A0=A0=A0secondary_startup_64+0xb6/0xc= 0 This is an early init code again so the lockdep sounds like a false possitive to me. --=20 Michal Hocko SUSE Labs