From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752083AbeAWPny (ORCPT ); Tue, 23 Jan 2018 10:43:54 -0500 Received: from mail-qt0-f196.google.com ([209.85.216.196]:41147 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751588AbeAWPnv (ORCPT ); Tue, 23 Jan 2018 10:43:51 -0500 X-Google-Smtp-Source: AH8x2245a13y0mVNdjPBU0oq3rt/hCMqIbaaUjjsOwZsPlPDOG1zcTf+CJjk3LlCLdFdRjxFSA6bWg== Date: Tue, 23 Jan 2018 07:43:47 -0800 From: Tejun Heo To: Steven Rostedt Cc: Sergey Senozhatsky , Sergey Senozhatsky , Petr Mladek , 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@rostedt.homelinux.com, Byungchul Park , Pavel Machek , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180123154347.GE1771050@devbig577.frc2.facebook.com> References: <20180117121251.7283a56e@gandalf.local.home> <20180117134201.0a9cbbbf@gandalf.local.home> <20180119132052.02b89626@gandalf.local.home> <20180120071402.GB8371@jagdpanzerIV> <20180120104931.1942483e@gandalf.local.home> <20180121141521.GA429@tigerII.localdomain> <20180123064023.GA492@jagdpanzerIV> <20180123095652.5e14da85@gandalf.local.home> <20180123152130.GB429@tigerII.localdomain> <20180123104121.2ef96d81@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180123104121.2ef96d81@gandalf.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 Hello, Steven. On Tue, Jan 23, 2018 at 10:41:21AM -0500, Steven Rostedt wrote: > > I don't want to have heuristics in print_safe, I don't want to have a magic > > number controlled by a user-space visible knob, I don't want to have the > > first 3 lines of a lockdep splat. > > We can have more. But if printk is causing printks, that's a major bug. > And work queues are not going to fix it, it will just spread out the > pain. Have it be 100 printks, it needs to be fixed if it is happening. > And having all printks just generate more printks is not helpful. Even > if we slow them down. They will still never end. So, at least in the case that we were seeing, it isn't that black and white. printk keeps causing printks but only because printk buffer flushing is preventing the printk'ing context from making forward progress. The key problem there is that a flushing context may get pinned flushing indefinitely and using a separate context does solve the problem. Thanks. -- tejun