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 00F74C4360C for ; Thu, 10 Oct 2019 18:06:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C020D214E0 for ; Thu, 10 Oct 2019 18:06:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C020D214E0 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 449E28E0005; Thu, 10 Oct 2019 14:06:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FA148E0003; Thu, 10 Oct 2019 14:06:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E9A98E0005; Thu, 10 Oct 2019 14:06:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 0E7D88E0003 for ; Thu, 10 Oct 2019 14:06:31 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 735C88243760 for ; Thu, 10 Oct 2019 18:06:30 +0000 (UTC) X-FDA: 76028654940.27.tent65_72f580acf7e35 X-HE-Tag: tent65_72f580acf7e35 X-Filterd-Recvd-Size: 4285 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Oct 2019 18:06:29 +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 2828BAE03; Thu, 10 Oct 2019 18:06:28 +0000 (UTC) Date: Thu, 10 Oct 2019 20:06:26 +0200 From: Michal Hocko To: Qian Cai Cc: Petr Mladek , 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: <20191010180626.GL18412@dhcp22.suse.cz> References: <20191009162339.GI6681@dhcp22.suse.cz> <6AAB77B5-092B-43E3-9F4B-0385DE1890D9@lca.pw> <20191010105927.GG18412@dhcp22.suse.cz> <1570713112.5937.26.camel@lca.pw> <20191010141820.GI18412@dhcp22.suse.cz> <1570718858.5937.28.camel@lca.pw> <20191010173040.GK18412@dhcp22.suse.cz> <1570729686.5937.30.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1570729686.5937.30.camel@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000013, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 10-10-19 13:48:06, Qian Cai wrote: > On Thu, 2019-10-10 at 19:30 +0200, Michal Hocko wrote: > > On Thu 10-10-19 10:47:38, Qian Cai wrote: > > > On Thu, 2019-10-10 at 16:18 +0200, Michal Hocko wrote: > > > > On Thu 10-10-19 09:11:52, Qian Cai wrote: > > > > > On Thu, 2019-10-10 at 12:59 +0200, Michal Hocko wrote: > > > > > > On Thu 10-10-19 05:01:44, Qian Cai wrote: > > > > > > >=20 > > > > > > >=20 > > > > > > > > On Oct 9, 2019, at 12:23 PM, Michal Hocko wrote: > > > > > > > >=20 > > > > > > > > If this was only about the memory offline code then I wou= ld agree. But > > > > > > > > we are talking about any printk from the zone->lock conte= xt and that is > > > > > > > > a bigger deal. Besides that it is quite natural that the = printk code > > > > > > > > should be more universal and allow to be also called from= the MM > > > > > > > > contexts as much as possible. If there is any really stro= ng reason this > > > > > > > > is not possible then it should be documented at least. > > > > > > >=20 > > > > > > > Where is the best place to document this? I am thinking abo= ut under > > > > > > > the =E2=80=9Cstruct zone=E2=80=9D definition=E2=80=99s lock= field in mmzone.h. > > > > > >=20 > > > > > > I am not sure TBH and I do not think we have reached the stat= e where > > > > > > this would be the only way forward. > > > > >=20 > > > > > How about I revised the changelog to focus on memory offline ra= ther than making > > > > > a rule that nobody should call printk() with zone->lock held? > > > >=20 > > > > If you are to remove the CONFIG_DEBUG_VM printk then I am all for= it. I > > > > am still not convinced that fiddling with dump_page in the isolat= ion > > > > code is justified though. > > >=20 > > > No, dump_page() there has to be fixed together for memory offline t= o be useful. > > > What's the other options it has here? > >=20 > > I would really prefer to not repeat myself > > http://lkml.kernel.org/r/20191010074049.GD18412@dhcp22.suse.cz >=20 > Care to elaborate what does that mean? I am confused on if you finally = agree on > no printk() while held zone->lock or not. You said "If there is absolut= ely > no way around that then we might have to bite a bullet and consider som= e > of MM locks a land of no printk." which makes me think you agreed, but = your > stance from the last reply seems you were opposite to it. I really do mean that the first step is to remove the dependency from the printk and remove any allocation from the console callbacks. If that turns out to be infeasible then we have to bite the bullet and think of a way to drop all printks from all locks that participate in an atomic allocation requests. --=20 Michal Hocko SUSE Labs