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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 9A5ECC4360C for ; Tue, 8 Oct 2019 13:42:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 68E6C206C0 for ; Tue, 8 Oct 2019 13:42:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68E6C206C0 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 0D5B08E0005; Tue, 8 Oct 2019 09:42:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 086D08E0003; Tue, 8 Oct 2019 09:42:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB7A38E0005; Tue, 8 Oct 2019 09:42:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id CDDBE8E0003 for ; Tue, 8 Oct 2019 09:42:58 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 67F4E180AD803 for ; Tue, 8 Oct 2019 13:42:58 +0000 (UTC) X-FDA: 76020733236.26.wind11_19eb6a04f515a X-HE-Tag: wind11_19eb6a04f515a X-Filterd-Recvd-Size: 3774 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Oct 2019 13:42:57 +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 8B3BDB1AB; Tue, 8 Oct 2019 13:42:56 +0000 (UTC) Date: Tue, 8 Oct 2019 15:42:56 +0200 From: Petr Mladek To: Qian Cai Cc: Steven Rostedt , sergey.senozhatsky.work@gmail.com, peterz@infradead.org, Michal Hocko , linux-mm@kvack.org, john.ogness@linutronix.de, akpm@linux-foundation.org, david@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk() Message-ID: <20191008134256.5ti6rjkvadn5b5q4@pathway.suse.cz> References:<1570228005-24979-1-git-send-email-cai@lca.pw> <20191007143002.l37bt2lzqtnqjqxu@pathway.suse.cz> <1570460350.5576.290.camel@lca.pw> <20191007151237.GP2381@dhcp22.suse.cz> <1570462407.5576.292.camel@lca.pw> <20191008081510.ptwmb7zflqiup5py@pathway.suse.cz> <20191008091349.6195830d@gandalf.local.home> <1570541032.5576.297.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To:<1570541032.5576.297.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 09:23:52, Qian Cai wrote: > On Tue, 2019-10-08 at 09:13 -0400, Steven Rostedt wrote: > > On Tue, 8 Oct 2019 10:15:10 +0200 > > Petr Mladek wrote: > > > > > There are basically three possibilities: > > > > > > 1. Do crazy exercises with locks all around the kernel to > > > avoid the deadlocks. It is usually not worth it. And > > > it is a "whack a mole" approach. > > > > > > 2. Use printk_deferred() in problematic code paths. It is > > > a "whack a mole" approach as well. And we would end up > > > with printk_deferred() used almost everywhere. > > > > > > 3. Always deffer the console handling in printk(). This would > > > help also to avoid soft lockups. Several people pushed > > > against this last few years because it might reduce > > > the chance to see the message in case of system crash. > > > > > > As I said, there has finally been agreement to always do > > > the offload few weeks ago. John Ogness is working on it. > > > So we might have the systematic solution for these deadlocks > > > rather sooner than later. > > > > Another solution is to add the printk_deferred() in these places that > > cause lockdep splats, and when John's work is done, it would be easy to > > grep for them and remove them as they would no longer be needed. > > > > This way we don't play whack-a-mole forever (only until we have a > > proper solution) and everyone is happy that we no longer have these > > false positive or I-don't-care lockdep splats which hide real lockdep > > splats because lockdep shuts off as soon as it discovers its first > > splat. > > I feel like that is what I trying to do, but there seems a lot of resistances > with that approach where pragmatism met with perfectionism. No, the resistance was against complicated code changes (games with locks) and against removing useful messages. Such changes might cause more harm than good. I am not -mm maintainer so I could not guarantee that a patch using printk_deferred() will get accepted. But it will have much bigger chance than the original patch. Anyway, printk_deferred() is a lost war. It is temporary solution for one particular scenario. But as you said, there might be many others. The long term solution is the printk rework. Best Regards, Petr