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 41EB6C33CB1 for ; Thu, 16 Jan 2020 15:54:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 031782073A for ; Thu, 16 Jan 2020 15:54:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 031782073A 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 A8EDE8E007A; Thu, 16 Jan 2020 10:54:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A647A8E003F; Thu, 16 Jan 2020 10:54:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9535F8E007A; Thu, 16 Jan 2020 10:54:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id 7E66E8E003F for ; Thu, 16 Jan 2020 10:54:37 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 4924B2C34 for ; Thu, 16 Jan 2020 15:54:37 +0000 (UTC) X-FDA: 76383944994.03.pie68_b321e51d0f1e X-HE-Tag: pie68_b321e51d0f1e X-Filterd-Recvd-Size: 4372 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jan 2020 15:54:36 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id f129so4356685wmf.2 for ; Thu, 16 Jan 2020 07:54:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=h2hhG4jWcxA95LxI7Qpc36hdp7bTXlmQIH0NAyxSMOM=; b=TkOFAyGLynZBGbUwdlZs9PlWUlvnKLCfIDsQgeZreE4UK7cNwxDGjNMQ7/aBenTsGl iADjKztMlhpsZsHKLDRKCH8SvN392FN/vWUQbqD9XNumLI3UQiJAi2krkLAOPHLkbHCl bH2MrlB54+Zb4O9c49LsOgjmGDIqVJ4pZnB5l7wjfII2IsKAWyl0u5IPbrwscexZ7GdL ZY32aAhK0BP6KuQMYQgX/Qak9P94Qpvz7GwHMFnFlGB9D675Zfm7/0DMI5p0IaQo/UKj YrhiBZNYeWlkBwt2S6ZWfUZoZbtP1pkWFp5lVjPe4vV6aBo7A3HIxc1oK6O30TG4W69q p3lQ== X-Gm-Message-State: APjAAAWrvwsEeLDuhNGefHJIHzsnpePR9KG6MGsnCYWFTUSTxsmAZ/lw xtYRkPiR8Ggvl0YjHnqTiHQ= X-Google-Smtp-Source: APXvYqwasirTn2mRHt5icpct1OzxtW+H1/bjOZhi54tv2uRe3d85H230iWIMdGxgg57kTjY/fesRKQ== X-Received: by 2002:a1c:44d:: with SMTP id 74mr19355wme.53.1579190075850; Thu, 16 Jan 2020 07:54:35 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id r5sm29390925wrt.43.2020.01.16.07.54.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2020 07:54:35 -0800 (PST) Date: Thu, 16 Jan 2020 16:54:34 +0100 From: Michal Hocko To: Qian Cai Cc: Andrew Morton , Sergey Senozhatsky , pmladek@suse.com, rostedt@goodmis.org, peterz@infradead.org, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -next v3] mm/hotplug: silence a lockdep splat with printk() Message-ID: <20200116155434.GB19428@dhcp22.suse.cz> References: <20200115172916.16277-1-cai@lca.pw> <20200116142827.GU19428@dhcp22.suse.cz> <162DFB9F-247F-4DCA-9B69-535B9D714FBB@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <162DFB9F-247F-4DCA-9B69-535B9D714FBB@lca.pw> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Thu 16-01-20 09:53:13, Qian Cai wrote: > > > > On Jan 16, 2020, at 9:28 AM, Michal Hocko wrote: > > > > On Wed 15-01-20 12:29:16, Qian Cai wrote: > >> It is guaranteed to trigger a lockdep splat if calling printk() with > >> zone->lock held because there are many places (tty, console drivers, > >> debugobjects etc) would allocate some memory with another lock > >> held which is proved to be difficult to fix them all. > > > > I am still not happy with the above much. What would say about something > > like below instead? > > " > > It is not that hard to trigger lockdep splats by calling printk from > > under zone->lock. Most of them are false positives caused by lock chains > > introduced early in the boot process and they do not cause any real > > problems. There are some console drivers which do allocate from the > > printk context as well and those should be fixed. In any case false > > positives are not that trivial to workaround and it is far from optimal > > to lose lockdep functionality for something that is a non-issue. > > > > " > > I feel like I repeated myself too many times. A call trace for one lock dependency > is sometimes from early boot process because lockdep will save the first one it > encountered, but it does not mean the lock dependency will only not happen in > early boot. I spent some time to study those early boot call traces in the given > lockdep splats, and it looks to me the lock dependency is also possible after > the boot. Then state it explicitly with an example of the trace and explanation that the deadlock is real. If the deadlock is real then it shouldn't be really terribly hard to notice even without lockdep splats which get disabled after the first false positive, right? -- Michal Hocko SUSE Labs