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.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 476CCECE596 for ; Thu, 10 Oct 2019 08:39:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EFC7821D7A for ; Thu, 10 Oct 2019 08:39:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aHI15Eqn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFC7821D7A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9C5068E0008; Thu, 10 Oct 2019 04:39:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 94E648E0003; Thu, 10 Oct 2019 04:39:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83E398E0008; Thu, 10 Oct 2019 04:39:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 61B5C8E0003 for ; Thu, 10 Oct 2019 04:39:17 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id ED72D75B0 for ; Thu, 10 Oct 2019 08:39:16 +0000 (UTC) X-FDA: 76027225512.21.dad17_6e19a97d7ba58 X-HE-Tag: dad17_6e19a97d7ba58 X-Filterd-Recvd-Size: 5249 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Oct 2019 08:39:16 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id q5so3409455pfg.13 for ; Thu, 10 Oct 2019 01:39:16 -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=RGh2rO2aZYwHa/Y1Cj8hBGbPD5Mu0Wu+i6Qq6LV4LEI=; b=aHI15Eqn17jVYTeOisUaG2auUiaQ9Nh+Y7ptTdWinJ1D3CXNzQAzCh2dgAqnt61w3B shS9tNsgTFeFis0h9W2AJaZ8WOu5myce8cgqJjQFZGe81ASkeqMBzHZXVL6TM0XrIo3s 7JaIPCbTICFYmy2d71zVsvFX5yjP5z/rBsgpzVV0K8c63MQCbpRIPzeyVBlSRny44Y2A XFs54k1CecH15wp7YrNupz+s8oA62/OlvvQ1AzWs/biKAYX5ggWeQCQwo1JaxNu+uKbT qzS6QPNOblP/TLgoj/yOmZyh6jqeV/ysNpy6UhH7VO4CxKr6rn4bKkUpndITvBBs9/R3 gmCg== 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=RGh2rO2aZYwHa/Y1Cj8hBGbPD5Mu0Wu+i6Qq6LV4LEI=; b=iQgRtDjLMfISB6o9U9bCufxcfbbiVd3o7uRcU/+PoV27WtPRkL7M+qhiItkwWEEiPD IUra9TMMqvKY27MhnrA6rnp6uD408pqLHyJYjOC7XO4gUwzU7QWABWOR2tLnzQVjV9WI 0+x7SOlOqQmFp9VnDAaGeS2MmigFEu3NP5YyWangOHz9c+qaMu6tWaYofeL0cHitxNKG tNl43SaAHK/ydzsyhAuyOaj7lB94nH256BrELOfoXvtrKYordZhT0NvkI+CmM0fMlcRD 5+kqcb/LoyTn+zgo/U3eNHc+tsikpheieox/wiPaOOh1bqXbPagoEEQ2CTjmxyuBMc2s UFjw== X-Gm-Message-State: APjAAAWy1mL1reEKy2PUMesWx9JpvWKZutZV3b3a1eZq0j5x7bo1GxFD YGwjYXoB9NnGNXS6bkHwVqc= X-Google-Smtp-Source: APXvYqxxJGpGtx+qnVTeAkt3lio/jTq+tq/6mQIKQBzMhZ3ZINbYhp1XjojUTNdL+hN8xqrkFn6Wsg== X-Received: by 2002:a65:66c3:: with SMTP id c3mr7121338pgw.448.1570696755438; Thu, 10 Oct 2019 01:39:15 -0700 (PDT) Received: from localhost ([2001:e60:1023:519f:3055:27ff:fe5a:5b5c]) by smtp.gmail.com with ESMTPSA id h4sm5010117pfg.159.2019.10.10.01.39.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Oct 2019 01:39:14 -0700 (PDT) Date: Thu, 10 Oct 2019 17:39:08 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Michal Hocko , Christian Borntraeger , Heiko Carstens , rostedt@goodmis.org, peterz@infradead.org, linux-mm@kvack.org, Qian Cai , 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: <20191010083908.GA2521@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> <20191010082110.dreavjarni7mkvv6@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191010082110.dreavjarni7mkvv6@pathway.suse.cz> User-Agent: Mutt/1.12.2 (2019-09-21) 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 (10/10/19 10:21), Petr Mladek 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?). > > > > But even more "commonly used" consoles sometimes break that > > expectation. E.g. 8250 > > > > serial8250_console_write() > > serial8250_modem_status() > > wake_up_interruptible() > > > > And so on. > > I think that the only maintainable solution is to call the console > drivers in a well defined context (kthread). We have finally opened > doors to do this change. Yeah, that's a pretty complex thing, I suspect. Panic flush to netcon may deadlock if oops occurs under one of those "important MM locks" (if any MM locks are actually involved in ATOMIC skb allocation). If there are such MM locks, then I think flush_on_panic issue can't be address by printing kthread or ->atomic_write callback. > Using printk_deferred() or removing the problematic printk() is > a short term workaround. I am not going to block such patches. > But the final decision will be on maintainers of the affected subsystems. Agreed. -ss