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 4AE3AECE58D for ; Wed, 9 Oct 2019 11:49:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1914B20659 for ; Wed, 9 Oct 2019 11:49:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1914B20659 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1AD198E0005; Wed, 9 Oct 2019 07:49:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15D818E0003; Wed, 9 Oct 2019 07:49:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04DBF8E0005; Wed, 9 Oct 2019 07:49:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0114.hostedemail.com [216.40.44.114]) by kanga.kvack.org (Postfix) with ESMTP id DA6AA8E0003 for ; Wed, 9 Oct 2019 07:49:05 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 8E8C468BD for ; Wed, 9 Oct 2019 11:49:05 +0000 (UTC) X-FDA: 76024075050.02.chain26_6c71f6b5ff73c X-HE-Tag: chain26_6c71f6b5ff73c X-Filterd-Recvd-Size: 3310 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 9 Oct 2019 11:49:05 +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 B5CF7B117; Wed, 9 Oct 2019 11:49:03 +0000 (UTC) Date: Wed, 9 Oct 2019 13:49:03 +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 , Peter Oberparleiter , david@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk() Message-ID: <20191009114903.aa6j6sa56z2cssom@pathway.suse.cz> References:<20191007143002.l37bt2lzqtnqjqxu@pathway.suse.cz> <20191007144937.GO2381@dhcp22.suse.cz> <20191008074357.f33f6pbs4cw5majk@pathway.suse.cz> <20191008082752.GB6681@dhcp22.suse.cz> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To:<1570563324.5576.309.camel@lca.pw> User-Agent: NeoMutt/20170912 (1.9.0) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 2019-10-08 15:35:24, Qian Cai wrote: > On Tue, 2019-10-08 at 21:17 +0200, Michal Hocko wrote: > > On Tue 08-10-19 15:06:13, Qian Cai wrote: > > > On Tue, 2019-10-08 at 20:35 +0200, Michal Hocko wrote: > > > > [...] > > > > I fully agree that this class of lockdep splats are annoying especially > > > > when they make the lockdep unusable but please discuss this with lockdep > > > > maintainers and try to find some solution rather than go and try to > > > > workaround the problem all over the place. If there are places that > > > > would result in a cleaner code then go for it but please do not make the > > > > code worse just because of a non existent problem flagged by a false > > > > positive. > > > > > > It makes me wonder what make you think it is a false positive for sure. > > > > Because this is an early init code? Because if it were a real deadlock > > No, that alone does not prove it is a false positive. There are many places > could generate that lock dependency but lockdep will always save the earliest > one. You are still mixing the pasted lockdep report and other situations that will not get reported because of the first one. We believe that the pasted report is pasted is false positive. And we are against complicating the code just to avoid this false positive. Are you sure that the workaround will not create real deadlocks or races? I see two realistic possibilities: + Make printk() always deferred. This will hopefully happen soon. + Improve lockdep so that false positives could get ignored without complicating the code. Best Regards, Petr