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.2 required=3.0 tests=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 A03B8C04EBF for ; Mon, 23 Sep 2019 12:58:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5338620820 for ; Mon, 23 Sep 2019 12:58:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5338620820 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9028A6B0006; Mon, 23 Sep 2019 08:58:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B5C96B0008; Mon, 23 Sep 2019 08:58:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A2316B000A; Mon, 23 Sep 2019 08:58:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id 591606B0006 for ; Mon, 23 Sep 2019 08:58:56 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 034F683ED for ; Mon, 23 Sep 2019 12:58:56 +0000 (UTC) X-FDA: 75966190272.19.drop67_4df214a81982e X-HE-Tag: drop67_4df214a81982e X-Filterd-Recvd-Size: 3291 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Sep 2019 12:58:55 +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 B0111AF4E; Mon, 23 Sep 2019 12:58:52 +0000 (UTC) Date: Mon, 23 Sep 2019 14:58:51 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Qian Cai , Catalin Marinas , Arnd Bergmann , Sergey Senozhatsky , Steven Rostedt , Peter Zijlstra , Dan Williams , Will Deacon , linux-mm@kvack.org, Thomas Gleixner , Greg Kroah-Hartman , linux-arm-kernel@lists.infradead.org, Theodore Ts'o , Waiman Long , linux-kernel@vger.kernel.org Subject: Re: printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang) Message-ID: <20190923125851.cykw55jpqwlerjrz@pathway.suse.cz> References:<1566509603.5576.10.camel@lca.pw> <1567717680.5576.104.camel@lca.pw> <1568128954.5576.129.camel@lca.pw> <20190911011008.GA4420@jagdpanzerIV> <1568289941.5576.140.camel@lca.pw> <20190916104239.124fc2e5@gandalf.local.home> <1568817579.5576.172.camel@lca.pw> <20190918155059.GA158834@tigerII.localdomain> <1568823006.5576.178.camel@lca.pw> <20190923102100.GA1171@jagdpanzerIV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To:<20190923102100.GA1171@jagdpanzerIV> User-Agent: NeoMutt/20170912 (1.9.0) 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 Mon 2019-09-23 19:21:00, Sergey Senozhatsky wrote: > So we have > > port->lock -> MM -> zone->lock > // from pty_write()->__tty_buffer_request_room()->kmalloc() > > vs > > zone->lock -> printk() -> port->lock > // from __offline_pages()->__offline_isolated_pages()->printk() If I understand it correctly then this is the re-appearing problem. The only systematic solution with the current approach is to take port->lock in printk_safe/printk_deferred context. But this is a massive change that almost nobody wants. Instead, we want the changes that were discussed on Plumbers. Now, the question is what to do with existing kernels. There were several lockdep reports. And I am a bit lost. Did anyone seen real deadlocks or just the lockdep reports? To be clear. I would feel more comfortable when there are no deadlocks. But I also do not want to invest too much time into old kernels. All these problems were there for ages. We could finally see them because lockdep was enabled in printk() thanks to printk_safe. Well, it is getting worse over time with the increasing complexity and number of debugging messages. > A number of debugging options make the kernel less stable. > Sad but true. Yeah. The only good thing is that most debug options are not enabled on production systems. It is not an excuse for ignoring the problems. But it might be important for prioritizing. Best Regards, Petr