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 C4907C4CED1 for ; Fri, 4 Oct 2019 14:41:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7180020659 for ; Fri, 4 Oct 2019 14:41:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7180020659 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 C7F046B0003; Fri, 4 Oct 2019 10:41:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C30448E0003; Fri, 4 Oct 2019 10:41:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1E436B0006; Fri, 4 Oct 2019 10:41:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0193.hostedemail.com [216.40.44.193]) by kanga.kvack.org (Postfix) with ESMTP id 8FF116B0003 for ; Fri, 4 Oct 2019 10:41:54 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 1C37D181AC9AE for ; Fri, 4 Oct 2019 14:41:54 +0000 (UTC) X-FDA: 76006366548.24.fold86_1087b55b4104f X-HE-Tag: fold86_1087b55b4104f X-Filterd-Recvd-Size: 3176 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Oct 2019 14:41:53 +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 D7730AC69; Fri, 4 Oct 2019 14:41:51 +0000 (UTC) Date: Fri, 4 Oct 2019 16:41:50 +0200 From: Michal Hocko To: Qian Cai Cc: Anshuman Khandual , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Oscar Salvador , Mel Gorman , Mike Rapoport , Dan Williams , Pavel Tatashin , linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages() Message-ID: <20191004144150.GO9578@dhcp22.suse.cz> References: <1570090257-25001-1-git-send-email-anshuman.khandual@arm.com> <20191004105824.GD9578@dhcp22.suse.cz> <91128b73-9a47-100b-d3de-e83f0b941e9f@arm.com> <1570193776.5576.270.camel@lca.pw> <20191004130713.GK9578@dhcp22.suse.cz> <1570195839.5576.273.camel@lca.pw> <20191004133814.GM9578@dhcp22.suse.cz> <1570197360.5576.275.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1570197360.5576.275.camel@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri 04-10-19 09:56:00, Qian Cai wrote: > On Fri, 2019-10-04 at 15:38 +0200, Michal Hocko wrote: > > On Fri 04-10-19 09:30:39, Qian Cai wrote: > > > On Fri, 2019-10-04 at 15:07 +0200, Michal Hocko wrote: > > > > On Fri 04-10-19 08:56:16, Qian Cai wrote: > > > > [...] > > > > > It might be a good time to rethink if it is really a good idea to dump_page() > > > > > at all inside has_unmovable_pages(). As it is right now, it is a a potential > > > > > deadlock between console vs memory offline. More details are in this thread, > > > > > > > > > > https://lore.kernel.org/lkml/1568817579.5576.172.camel@lca.pw/ > > > > > > > > Huh. That would imply we cannot do any printk from that path, no? > > > > > > Yes, or use something like printk_deferred() > > > > This is just insane. The hotplug code is in no way special wrt printk. > > It is never called from the printk code AFAIK and thus there is no real > > reason why this particular code should be any special. Not to mention > > it calls printk indirectly from a code that is shared with other code > > paths. > > Basically, printk() while holding the zone_lock will be problematic as console > is doing the opposite as it always needs to allocate some memory. Then, it will > always find some way to form this chain, > > console_lock -> * -> zone_lock. So this is not as much a hotplug specific problem but zone->lock -> printk -> alloc chain that is a problem, right? Who is doing an allocation from this atomic context? I do not see any atomic allocation in kernel/printk/printk.c. -- Michal Hocko SUSE Labs