Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp2053102ybp; Thu, 10 Oct 2019 01:18:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqwfM35hH95OIr50pNK1j6jbnu38WFrfDzcJiYoNsf52zXR2cuuoIsCPR8yn8Pno8UwBDVBt X-Received: by 2002:a17:906:46c7:: with SMTP id k7mr6990404ejs.112.1570695491060; Thu, 10 Oct 2019 01:18:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570695491; cv=none; d=google.com; s=arc-20160816; b=DlBlUOUhB94mjrGuBdi0EJdYS+ESLeL3MtqjoX/xBzog2U8CSWIb2nQ1UIGIx6WwSZ iVqmHAiDS8KlSRGVuCh6IuvEGQ6EWI3Yl+rkCEf8fBIWm0DuaI7rl9+4nFQc+CO0Fcwg RUvtt//To9Ph2qquQcrX5+2N+zuGzGJIy6dy+EiuibDpUQyI/KQuBOFZ1pruTuEZUZ6p WWVw0Jt2WNdr2L4+aPqASZgCVTsznzYOXXFzTyhH88lG4S8Hg9ayBdXpZk/Qoy6/9uS0 1xlBZiDm35a4Yc/akpc4WJ8To0mQ0naBsu/7Nm11aKOUEUx+5W9+562FVdhERVwGls9L Glfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=lIULWAfJ8ac9fSRouaYXz9QL/7zsR+COixG8JRGBZzA=; b=CWl7Uzuc+crZjBNJV8BqJWIK+UYUjSzDubTrswxGMI1SZjXjNj0E4Ij4S4h7GdAu67 2EHRW4172Z9bhSE1xpJl1kNdRZ0+EK/dE+mRYATKhJ8UgzjUEz+r8xeFavvFmeSnqfGp u6Ox9bi8UDpiYFaBJARTCx3/Zb5Ceszrt6NrxzpMZ94ivwCTvkvQmoG5OL6Hj133JaH5 D1hFcMgTXDxXwvpreDXhb0Dt6qodN6Tezp/d7yE7XM/EF8q/2XpIC6EP0uHpvSbQpJOz 15L8kk6QwV0/FUlUwWp/kpwPmifkPgQdxwXytXmW27Eybulo/waMqNeqryvzEKZzmC+3 D9yA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NvJGQsSw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h20si2980504edb.218.2019.10.10.01.17.47; Thu, 10 Oct 2019 01:18:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NvJGQsSw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733272AbfJJIQg (ORCPT + 99 others); Thu, 10 Oct 2019 04:16:36 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:38139 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733057AbfJJIQf (ORCPT ); Thu, 10 Oct 2019 04:16:35 -0400 Received: by mail-pf1-f193.google.com with SMTP id h195so3393860pfe.5 for ; Thu, 10 Oct 2019 01:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lIULWAfJ8ac9fSRouaYXz9QL/7zsR+COixG8JRGBZzA=; b=NvJGQsSwWbWweA9LHYTJ8PuRliMxWzd18o25n1mhCy6KzS00qvFaE/RDQ4uOipOYhO zOgBOMV7OABG7hRFBMgnM6U9SafQHxCzghs68GgX4iSwS1uVivWjCKM8E8vrtfSw/eGF RS3szEUX5yGJVun6BNw8WP+Pxecokkzcpu9UZ7pwUXcfGppj+OIHFebGgz9tiAR1WI0B asMAmBbyPf5ITdPU1HvPY8QegTcm2bV+kIvshnI3VmN6wfXV+F5dau42Pc8kWs72bds3 nvxBc6emr0N5R85BoIfQ9dD5yso3SoimpFJbq1jOCzDy3022+HLmnDf4/2f5/W62K7AX ccBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lIULWAfJ8ac9fSRouaYXz9QL/7zsR+COixG8JRGBZzA=; b=tkRxAH0PnM7ibz8yhp17WrVxYK/Y6BT6QlQi5Jzwn3OIsOkTs7vSZW8QdqU0tAyDKE A2r5ZIZ98lZysPkQC6k8BOFmKWWwldmw/4JTOqSaUIGhz2mEIVf62nUpBQ5oHiuRCl6h CNDhCG/j/NasgpyU+pgBbvyWaEmsoaxSWzdVEtYVpEPOC5jL9Ie8O5K1QAT0V/bno2Mw ADezfz81ja0NrRex8PZY8mIHo1LHkMDduwhdv3TCF7zEu0/lcxaLqQ6irTpieGWgkv0W p5WBu0v51XkJWUZt5jEVDn7mLGZIb97aAqmlAxlA4BnUErSNFFpU2oe6eMxXZy1gsTlZ pBeQ== X-Gm-Message-State: APjAAAXGKu7UZ6g3XiquPYk6QajuUj/cGmorPaChsuYV6QNWMN6lGFll +aQScmGFyRwbyuX2IwIRMsM= X-Received: by 2002:a63:5516:: with SMTP id j22mr9594111pgb.201.1570695394874; Thu, 10 Oct 2019 01:16:34 -0700 (PDT) Received: from localhost ([2001:e60:1023:519f:3055:27ff:fe5a:5b5c]) by smtp.gmail.com with ESMTPSA id v68sm5519387pfv.47.2019.10.10.01.16.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Oct 2019 01:16:33 -0700 (PDT) Date: Thu, 10 Oct 2019 17:16:29 +0900 From: Sergey Senozhatsky To: Michal Hocko Cc: Sergey Senozhatsky , Peter Oberparleiter , Qian Cai , Christian Borntraeger , Petr Mladek , akpm@linux-foundation.org, rostedt@goodmis.org, peterz@infradead.org, linux-mm@kvack.org, john.ogness@linutronix.de, david@redhat.com, linux-kernel@vger.kernel.org, Heiko Carstens , Vasily Gorbik Subject: Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk() Message-ID: <20191010081629.GA120986@jagdpanzerIV> References: <20191007143002.l37bt2lzqtnqjqxu@pathway.suse.cz> <20191007144937.GO2381@dhcp22.suse.cz> <20191008074357.f33f6pbs4cw5majk@pathway.suse.cz> <20191008082752.GB6681@dhcp22.suse.cz> <1570550917.5576.303.camel@lca.pw> <1157b3ae-006e-5b8e-71f0-883918992ecc@linux.ibm.com> <20191009142623.GE6681@dhcp22.suse.cz> <20191010051201.GA78180@jagdpanzerIV> <20191010074049.GD18412@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191010074049.GD18412@dhcp22.suse.cz> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (10/10/19 09:40), Michal Hocko wrote: [..] > > > Considering that console.write is called from essentially arbitrary code > > > path IIUC then all the locks used in this path should be pretty much > > > tail locks or console internal ones without external dependencies. > > > > That's a good expectation, but I guess it's not always the case. > > > > One example might be NET console - net subsystem locks, net device > > drivers locks, maybe even some MM locks (skb allocations?). > > I am not familiar with the netconsole code TBH. If there is absolutely > no way around that then we might have to bite a bullet and consider some > of MM locks a land of no printk. So this is what netconsole does (before we pass on udp to net device driver code, which *may be* can do more allocations, I don't know): write_msg() netpoll_send_udp() find_skb() alloc_skb(len, GFP_ATOMIC) kmem_cache_alloc_node() You are the right person to ask this question to - how many MM locks are involved when we do GFP_ATOMIC kmem_cache allocation? Is there anything to be concerned about? > I have already said that in this thread. I am mostly pushing back > on "let's just go the simplest way" approach. I understand this. And don't have objections. Merely trying to get better understanding. > > But even more "commonly used" consoles sometimes break that > > expectation. E.g. 8250 > > > > serial8250_console_write() > > serial8250_modem_status() > > wake_up_interruptible() > > By that expectation you mean they are using external locks or that they > really _need_ to allocate. Sort of both. netconsole does allocations and has external lock dependencies. Some of serial console drivers have external lock dependencies (but don't do allocations, as far as I'm concerned). > Because if you are pointing to wake_up_interruptible and therefore the rq > then this is a well known thing and I was under impression even documented > but I can only see LOGLEVEL_SCHED that is arguably a very obscure way to > document the fact. That's right. All I was commenting on is that console.write() callbacks have external lock dependencies. -ss