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=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,MIME_QP_LONG_LINE,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 0973CC47404 for ; Sun, 6 Oct 2019 01:56:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B6F02218AC for ; Sun, 6 Oct 2019 01:56:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="S+ilh3D9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6F02218AC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 53ED56B0003; Sat, 5 Oct 2019 21:56:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EF3C6B0006; Sat, 5 Oct 2019 21:56:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DE566B0007; Sat, 5 Oct 2019 21:56:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2039D6B0003 for ; Sat, 5 Oct 2019 21:56:14 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id B40F63A9B for ; Sun, 6 Oct 2019 01:56:13 +0000 (UTC) X-FDA: 76011694626.12.look09_8da16bc1a2a0d X-HE-Tag: look09_8da16bc1a2a0d X-Filterd-Recvd-Size: 5505 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Sun, 6 Oct 2019 01:56:13 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id w14so14210154qto.9 for ; Sat, 05 Oct 2019 18:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=imOGVXBC+/p9vStT4U0IbeO04/RIxaJPoXiib9QhWwg=; b=S+ilh3D9wkYdDeWShD1N9ATSWwAI/owCVtu8Q2+Mb1Hj9wNiOMK8vF+X22O4KyyrwI TEmwDcWuv+Hbb81wOXdCh7PUBpMRTFOCL13xF4eWFtlJug4W2qUTj2E245TYG1U8DsF7 fkojJuRSJnVXP0N5z5t3JXArxrLHIeXZnJIE8WKckS+1ydS/y1xRnBUU1YJ9v1BKnORn XMNzN2CZ5s0QUgMLIS7cWziKhvQEi36BQz2M3Lhma2I6mtP1mwAbjSUai7gbpg2K8qHa D0wLHTdu8ittnJkp+Pq9nKVeW0ag7Fi7pGOvZfj8CgYHnC/TixBWuKMA1GPtiQKZ6I/R UKaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=imOGVXBC+/p9vStT4U0IbeO04/RIxaJPoXiib9QhWwg=; b=emgbrUiNoeKmdwJfEpgT1aSQu/u67yUwzz6+3btfSrTbJHQWOSZ/N7Af8fjM6Oz4pH VpWqutOuc2jFm2Ugg1kkquMHeOpGky7dsOatJr/iBnoXFaHZRfr9bk1mAiI17tDvvCZo JDSnIvtaIqtAHDAZIKGJXevBsXf/g2uCySRvNLVSVjq5DmY76VsAhMS0Y1v6sJXRd6d0 7qJVBd3VTbMQfEtrhqLqdDeCf5RHAkFhP24SnY2WIs1LoelCXnCdVih4ZWANaMTPjkSN vGSZisRG4bNpibUrOgLP6j5Ns8OxVn+CHtAzkB4MTtXIxMtwAn+haKjqrOqQgS4U306z XQZA== X-Gm-Message-State: APjAAAVXy2FEEy3rY+g7OMzcGOXzAi/owOKocELdlIkakvHc4q1An9xX KlqfnFJAnsN/82B4c5E+nzT0pQ== X-Google-Smtp-Source: APXvYqx6XPKlYgXhUA1U139/twJ8Ct78EQf11+03h2Y+OzBJqVT65J8Wj7ghHkFYMC31TtEGi7YAjQ== X-Received: by 2002:ac8:3b52:: with SMTP id r18mr24597309qtf.62.1570326972596; Sat, 05 Oct 2019 18:56:12 -0700 (PDT) Received: from [192.168.1.183] (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id c201sm5660055qke.128.2019.10.05.18.56.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Oct 2019 18:56:11 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E5A474C2-D1CB-40E1-9D18-4A9AA2F7100D Content-Transfer-Encoding: 7bit From: Qian Cai Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] mm/page_isolation: fix a deadlock with printk() Date: Sat, 5 Oct 2019 21:56:11 -0400 Message-Id: References: <20191005174423.23f2db80872a9365009f398a@linux-foundation.org> Cc: mhocko@kernel.org, sergey.senozhatsky.work@gmail.com, pmladek@suse.com, rostedt@goodmis.org, peterz@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org In-Reply-To: <20191005174423.23f2db80872a9365009f398a@linux-foundation.org> To: Andrew Morton X-Mailer: iPhone Mail (17A860) 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: --Apple-Mail-E5A474C2-D1CB-40E1-9D18-4A9AA2F7100D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Oct 5, 2019, at 8:44 PM, Andrew Morton wrot= e: >=20 > "ease" isn't the main objective. A more important question is "what > makes sense". We should be able to call printk() from anywhere, any > time under any conditions. That can't be done 100% but it is the > objective. printk() should be robust and not being able to call > printk() while holding zone->lock isn't robust! https://github.com/torvalds/linux/commit/dbdda842fe96f8932bae554f0adf463c27c= 42bc7 If you look at the above commit, it explicitly call out the possible deadloc= k scenarios and recommend to call printk_deferred() instead in those areas o= f code where zone->lock looks like one of those candidates. --Apple-Mail-E5A474C2-D1CB-40E1-9D18-4A9AA2F7100D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Oct 5, 2019, at 8:44 PM, Andrew Morton <= ;akpm@linux-foundation.org> wrote:

"ease" isn't the main objective.  A= more important question is "what
makes sense".  We sho= uld be able to call printk() from anywhere, any
time under a= ny conditions.  That can't be done 100% but it is the
o= bjective.  printk() should be robust and not being able to call<= br>printk() while holding zone->lock isn't robust!


If yo= u look at the above commit, it explicitly call out the possible deadlock sce= narios and recommend to call printk_deferred() instead in those areas of cod= e where zone->lock looks like one of those candidates.

= --Apple-Mail-E5A474C2-D1CB-40E1-9D18-4A9AA2F7100D--