Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp998810ybp; Wed, 9 Oct 2019 07:27:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqx0AD3A81i9qkt04zRKQsh8No1s8q+CogRuqxpQXpkyknzOFJNPvpSaRORe8pg8KbIv4l/4 X-Received: by 2002:a17:906:4748:: with SMTP id j8mr3186743ejs.210.1570631246112; Wed, 09 Oct 2019 07:27:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570631246; cv=none; d=google.com; s=arc-20160816; b=wqS7yukr2SK2jOjiW2EHggXnB7uPcuEfR2wxNhXqIWkR0iE+cunzEzgH8/VEox+adf XdxIMePKoQF9XHWrZB3jpKf/kvpW7r7jMImsOLwMQyU5Kf6Vr8kDxe1JjzywzKnCLDJm eAneuji9QGEpQJ+qUbTO43r+SMnapdCMHVleeVAZt4TcXtCl21G5o8P4Sjs/XCmyOfEy TGUT/WPvR2rtuS3LCpVWlu+fRgCk2Ztm/TWRMQwnr1lfUY9rY1pEdsupWTCUH6KRsdav 0Flpr1F9e15dBBAFlRp+nWwk2jmZ+7co5JRBZmxqDuivnSvhYZR4C2iW5pveiR81VnFL 8nng== 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; bh=0YjPLgrmubNIEPDHwAqaq9WOMdQQMXJ1tiX+PCYDESo=; b=sIFYq+wSd1yv+yV3I1xX0c3KL+2pEl6mhSW6o6MbMxtmPic3a0GOh7KAwZzEt4yyJP N0Jz0Y8yr43Mv76NNBpmp8UF2dx7pXu/SKzWbm50rq0krI0z6kpqZztVR0SjJI2x338f ntIKilw0OWUzy2x1gfbGLzTJ91EuqCkk8NkZHk/+WgjhvsetLrSj9/dAUGJXjyqR8DVQ Hm6Gh1vm6cSmlGXFksmT8ecPbhoNKHqiOgHvpNQlPXQgQHBdQx3oSz07rvwF73wJKc6Z bRn1rrGOwtuVtwPiJkrIdO2RAmb+kWVvC1hwLmaEVVXUyiTRZhuq7ylPzx55u04RINfM V+zw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l6si1231095eje.176.2019.10.09.07.27.01; Wed, 09 Oct 2019 07:27:26 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731513AbfJIO0Z (ORCPT + 99 others); Wed, 9 Oct 2019 10:26:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:56032 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727769AbfJIO0Z (ORCPT ); Wed, 9 Oct 2019 10:26:25 -0400 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 7364CAD2C; Wed, 9 Oct 2019 14:26:23 +0000 (UTC) Date: Wed, 9 Oct 2019 16:26:23 +0200 From: Michal Hocko To: Peter Oberparleiter Cc: Qian Cai , Christian Borntraeger , Petr Mladek , akpm@linux-foundation.org, sergey.senozhatsky.work@gmail.com, 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: <20191009142623.GE6681@dhcp22.suse.cz> References: <1570228005-24979-1-git-send-email-cai@lca.pw> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1157b3ae-006e-5b8e-71f0-883918992ecc@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 09-10-19 15:56:32, Peter Oberparleiter wrote: [...] > A generic solution would be preferable from my point of view though, > because otherwise each console driver owner would need to ensure that any > lock taken in their console.write implementation is never held while > memory is allocated/released. 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. Otherwise we are in a whack a mole situation chasing very complex lock chains. -- Michal Hocko SUSE Labs