From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753187AbeAJS5w (ORCPT + 1 other); Wed, 10 Jan 2018 13:57:52 -0500 Received: from mail-qk0-f171.google.com ([209.85.220.171]:37479 "EHLO mail-qk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752239AbeAJS5v (ORCPT ); Wed, 10 Jan 2018 13:57:51 -0500 X-Google-Smtp-Source: ACJfBos52TdtiCww0357wK7fWraeX+MVAXvHBAZtFJcfOYoYUw8sX/Nfa3VOb/Mh3ZEo/ihKc6G0Ew== Date: Wed, 10 Jan 2018 10:57:47 -0800 From: Tejun Heo To: Steven Rostedt Cc: Petr Mladek , Sergey Senozhatsky , akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus Torvalds , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , rostedt@home.goodmis.org, Byungchul Park , Sergey Senozhatsky , Pavel Machek , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180110185747.GO3668920@devbig577.frc2.facebook.com> References: <20180110132418.7080-1-pmladek@suse.com> <20180110140547.GZ3668920@devbig577.frc2.facebook.com> <20180110130517.6ff91716@vmware.local.home> <20180110181252.GK3668920@devbig577.frc2.facebook.com> <20180110134157.1c3ce4b9@vmware.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180110134157.1c3ce4b9@vmware.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hello, Steven. On Wed, Jan 10, 2018 at 01:41:57PM -0500, Steven Rostedt wrote: > The issue with the solution you want to do with printk is that it can > break existing printk usages. As Petr said, people want printk to do two > things. 1 - print out data ASAP, 2 - not lock up the system. The two > are fighting each other. You care more about 2 where I (and others, > like Peter Zijlstra and Linus) care more about 1. > > My solution can help with 2 without doing anything to hurt 1. I'm not really sure why punting to a safe context is necessarily unacceptable in terms of #1 because there seems to be a pretty wide gap between printing useful messages synchronously and a system being caught in printk flush to the point where the system is not operational at all. > You are NACKing my solution because it doesn't solve this bug with net > console. I believe net console should be fixed. You believe that printk > should have a work around to not let net console type bugs occur. Which > to me is papering over the real bugs. As I wrote along with nack, I was more concerned with how this was pushed forward by saying that actual problems are not real. As for the netconsole part, sure, that can be one way, but please consider that the messages could be coming from network drivers, of which we have many and a lot of them aren't too high quality. Plus, netconsole is a separate path and network drivers can easily malfunction on memory allocation failures. Again, not a critical problem. We can decide either way but it'd be better to be generally safe (if we can do that reasonably), right? Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) by kanga.kvack.org (Postfix) with ESMTP id 053626B0069 for ; Wed, 10 Jan 2018 14:07:03 -0500 (EST) Received: by mail-qk0-f198.google.com with SMTP id j141so71185qke.4 for ; Wed, 10 Jan 2018 11:07:03 -0800 (PST) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id m6sor12204836qki.145.2018.01.10.10.57.50 for (Google Transport Security); Wed, 10 Jan 2018 10:57:50 -0800 (PST) Date: Wed, 10 Jan 2018 10:57:47 -0800 From: Tejun Heo Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180110185747.GO3668920@devbig577.frc2.facebook.com> References: <20180110132418.7080-1-pmladek@suse.com> <20180110140547.GZ3668920@devbig577.frc2.facebook.com> <20180110130517.6ff91716@vmware.local.home> <20180110181252.GK3668920@devbig577.frc2.facebook.com> <20180110134157.1c3ce4b9@vmware.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180110134157.1c3ce4b9@vmware.local.home> Sender: owner-linux-mm@kvack.org List-ID: To: Steven Rostedt Cc: Petr Mladek , Sergey Senozhatsky , akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus Torvalds , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , rostedt@home.goodmis.org, Byungchul Park , Sergey Senozhatsky , Pavel Machek , linux-kernel@vger.kernel.org Hello, Steven. On Wed, Jan 10, 2018 at 01:41:57PM -0500, Steven Rostedt wrote: > The issue with the solution you want to do with printk is that it can > break existing printk usages. As Petr said, people want printk to do two > things. 1 - print out data ASAP, 2 - not lock up the system. The two > are fighting each other. You care more about 2 where I (and others, > like Peter Zijlstra and Linus) care more about 1. > > My solution can help with 2 without doing anything to hurt 1. I'm not really sure why punting to a safe context is necessarily unacceptable in terms of #1 because there seems to be a pretty wide gap between printing useful messages synchronously and a system being caught in printk flush to the point where the system is not operational at all. > You are NACKing my solution because it doesn't solve this bug with net > console. I believe net console should be fixed. You believe that printk > should have a work around to not let net console type bugs occur. Which > to me is papering over the real bugs. As I wrote along with nack, I was more concerned with how this was pushed forward by saying that actual problems are not real. As for the netconsole part, sure, that can be one way, but please consider that the messages could be coming from network drivers, of which we have many and a lot of them aren't too high quality. Plus, netconsole is a separate path and network drivers can easily malfunction on memory allocation failures. Again, not a critical problem. We can decide either way but it'd be better to be generally safe (if we can do that reasonably), right? Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org