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 F33CFC47404 for ; Mon, 7 Oct 2019 11:37:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BAFAE2173B for ; Mon, 7 Oct 2019 11:37:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAFAE2173B 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 657408E0005; Mon, 7 Oct 2019 07:37:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6086D8E0003; Mon, 7 Oct 2019 07:37:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 544F48E0005; Mon, 7 Oct 2019 07:37:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id 2DFF88E0003 for ; Mon, 7 Oct 2019 07:37:13 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 8AD1655FB0 for ; Mon, 7 Oct 2019 11:37:12 +0000 (UTC) X-FDA: 76016787504.06.range68_21cb9455db84e X-HE-Tag: range68_21cb9455db84e X-Filterd-Recvd-Size: 2981 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Oct 2019 11:37:12 +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 E6C7FAE65; Mon, 7 Oct 2019 11:37:10 +0000 (UTC) Date: Mon, 7 Oct 2019 13:37:10 +0200 From: Michal Hocko To: Qian Cai Cc: akpm@linux-foundation.org, sergey.senozhatsky.work@gmail.com, pmladek@suse.com, rostedt@goodmis.org, peterz@infradead.org, david@redhat.com, john.ogness@linutronix.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk() Message-ID: <20191007113710.GH2381@dhcp22.suse.cz> References: <20191007080742.GD2381@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 Mon 07-10-19 07:04:00, Qian Cai wrote: >=20 >=20 > > On Oct 7, 2019, at 4:07 AM, Michal Hocko wrote: > >=20 > > I do not think that removing the printk is the right long term soluti= on. > > While I do agree that removing the debugging printk __offline_isolate= d_pages > > does make sense because it is essentially of a very limited use, this > > doesn't really solve the underlying problem. There are likely other > > printks from zone->lock. It would be much more saner to actually > > disallow consoles to allocate any memory while printk is called from = an > > atomic context. >=20 > No, there is only a handful of places called printk() from > zone->lock. It is normal that the callers will quietly process > =E2=80=9Cstruct zone=E2=80=9D modification in a short section with zone= ->lock > held. It is extremely error prone to have any zone->lock vs. printk dependency. I do not want to play an endless whack a mole. > No, it is not about =E2=80=9Callocate any memory while printk is called= from an > atomic context=E2=80=9D. It is opposite lock chain from different proc= essors which has the same effect. For example, >=20 > CPU0: CPU1: CPU2: > console_owner > sclp_lock > sclp_lock zone_lock > zone_lock > console_owner Why would sclp_lock ever take a zone->lock (apart from an allocation). So really if sclp_lock is a lock that might be taken from many contexts and generate very subtle lock dependencies then it should better be really careful what it is calling into. In other words you are trying to fix a wrong end of the problem. Fix the console to not allocate or depend on MM by other means. --=20 Michal Hocko SUSE Labs