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 C00D7C33CB1 for ; Wed, 15 Jan 2020 09:53:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8B51A207FF for ; Wed, 15 Jan 2020 09:53:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B51A207FF 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 267E68E000E; Wed, 15 Jan 2020 04:53:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2182E8E0003; Wed, 15 Jan 2020 04:53:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 107338E000E; Wed, 15 Jan 2020 04:53:31 -0500 (EST) 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 EA9BA8E0003 for ; Wed, 15 Jan 2020 04:53:30 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 6D6BF180AD820 for ; Wed, 15 Jan 2020 09:53:29 +0000 (UTC) X-FDA: 76379406138.04.feet91_10038ba74001 X-HE-Tag: feet91_10038ba74001 X-Filterd-Recvd-Size: 2943 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jan 2020 09:53:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C9B23AC2C; Wed, 15 Jan 2020 09:52:54 +0000 (UTC) Date: Wed, 15 Jan 2020 10:52:53 +0100 From: Petr Mladek To: Qian Cai Cc: Michal Hocko , David Hildenbrand , akpm@linux-foundation.org, sergey.senozhatsky.work@gmail.com, rostedt@goodmis.org, peterz@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -next] mm/hotplug: silence a lockdep splat with printk() Message-ID: <20200115095253.36e5iqn77n4exj3s@pathway.suse.cz> References:<20200114210215.GQ19428@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170912 (1.9.0) Content-Transfer-Encoding: quoted-printable 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 2020-01-14 16:40:49, Qian Cai wrote: >=20 >=20 > > On Jan 14, 2020, at 4:02 PM, Michal Hocko wrote: > >=20 > > Yeah, that was a long discussion with a lot of lockdep false positive= s. > > I believe I have made it clear that the console code shouldn't depend= on > > memory allocation because that is just too fragile. If that is not > > possible for some reason then it has to be mentioned in the changelog= . > > I really do not want us to add kludges to the MM code just because of > > printk deficiencies unless that is absolutely inevitable. >=20 > I don=E2=80=99t know how to convince you, but both random number genera= tor > and printk() maintainers agreed to get ride of printk() with > zone->lock held as you can see in the approved commit mentioned I neither acked nor blocked the fix in the random generator. I believe that it was false positive. But the fix was trivial and I did not have any better solution in the pocket. > in this patch description because it is a whac-a-mole to fix other > places. This is misleading. Using printk_deferred() in _warn_unseeded_randomness() is whack-a-mole approach as well. The most realistic real solution is to deffer consoles into kthreads. It is being discussed for years. There is finally an agreement to get this upstream. But the priority is to add lockless ringbuffer first. I could understand that Michal is against hack in -mm code that would just hide a false positive warning. If you really need a solution before the console offload gets upstream then I suggest to do something really simple. For example, disable lockdep around the allocation in console registration code that is proven to produce the false positive chain. Best Regards, Petr