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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 6408CC47404 for ; Sat, 5 Oct 2019 21:22:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0774E222C8 for ; Sat, 5 Oct 2019 21:22:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Vomw4Odz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0774E222C8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7B8946B0003; Sat, 5 Oct 2019 17:22:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 769826B0005; Sat, 5 Oct 2019 17:22:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 658BB6B0006; Sat, 5 Oct 2019 17:22:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id 43A5B6B0003 for ; Sat, 5 Oct 2019 17:22:36 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id C8BF182437CF for ; Sat, 5 Oct 2019 21:22:35 +0000 (UTC) X-FDA: 76011005070.11.love56_50ce9962b7632 X-HE-Tag: love56_50ce9962b7632 X-Filterd-Recvd-Size: 3235 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Sat, 5 Oct 2019 21:22:35 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 76E39222C5; Sat, 5 Oct 2019 21:22:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570310553; bh=b2ojuscvA5vHZZCIRcmyr63IQh+4Z67dn4JCAN9oUvI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Vomw4Odzzw6K7rO6NN4INokEnUY6gIv4thk7COYozO8+LUEx2QuMV+Pq8PZVl+7oa Nx5x+M1wSdYtnKovrxGVdUAzPbhBR+C04UtI6ublLEyzQxdZKdUWvDyYP07mNo5cbN LpFB/bMGN6ywLBW0Gt6P5gpkqiWgnYJpxSvNwIgo= Date: Sat, 5 Oct 2019 14:22:32 -0700 From: Andrew Morton To: Michal Hocko Cc: Qian Cai , Anshuman Khandual , linux-mm@kvack.org, 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: <20191005142232.e08976cf8905824fad0533ff@linux-foundation.org> In-Reply-To: <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> <20191004144150.GO9578@dhcp22.suse.cz> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Fri, 4 Oct 2019 16:41:50 +0200 Michal Hocko wrote: > > > 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. Apparently some console drivers can do memory allocation on the printk() path. This behavior is daft, IMO. Have we identified which ones and looked into fixing them?