From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752432AbdKGCEx (ORCPT ); Mon, 6 Nov 2017 21:04:53 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:52946 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751525AbdKGCEj (ORCPT ); Mon, 6 Nov 2017 21:04:39 -0500 X-Google-Smtp-Source: ABhQp+TuSzDVqyJWGgwKb0Vmp/Mm757JPuNmUFWXpKnKJiirf1kidWK8suglf1F3e+HKi7Td7sytWw== Date: Tue, 7 Nov 2017 11:04:34 +0900 From: Sergey Senozhatsky To: Tejun Heo Cc: Sergey Senozhatsky , Petr Mladek , Steven Rostedt , linux-kernel@vger.kernel.org, kernel-team@fb.com, Linus Torvalds , Andrew Morton Subject: Re: [PATCH 2/2] Subject: printk: Don't trap random context in infinite log_buf flush Message-ID: <20171107020434.GC1822@jagdpanzerIV> References: <20171102135146.GN3252168@devbig577.frc2.facebook.com> <20171102135258.GO3252168@devbig577.frc2.facebook.com> <20171104042408.GB539@tigerII.localdomain> <20171107002254.GI3252168@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171107002254.GI3252168@devbig577.frc2.facebook.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tejun, On (11/06/17 16:22), Tejun Heo wrote: > Hello, > > On Sat, Nov 04, 2017 at 01:24:08PM +0900, Sergey Senozhatsky wrote: > > thanks for the patch set. we are currently looking at another approach: > > lkml.kernel.org/r/20171102134515.6eef16de@gandalf.local.home > > > > would you be interested in taking a look? > > Hmm... It took some tweaking but the code at the end locks up the > machine w/ Steven's patch applied and it's not that contrived a case > (e.g. out of memory messages from packet tx/rx paths while OOM is in > progress). thanks! just to make sure. there is a typo in Steven's patch: while (!READ_ONCE(console_waiter)) should be while (READ_ONCE(console_waiter)) is this the "tweaking" you are talking about? > > there are some concerns, like a huge number of printk-s happening while > > console_sem is locked. e.g. console_lock()/console_unlock() on one of the > > CPUs, or console_lock(); printk(); ... printk(); console_unlock(); > > Unless we make all messages fully synchronous, I don't think there's a > good solution for that and I don't think we wanna make everything > fully synchronous. this is where it becomes complicated. offloading logic is not binary, unfortunately. we normally want to offload; but not always. things like sysrq or late PM warnings, or kexec, etc. want to stay fully sync, regardless the consequences. some of sysrq prints out even do touch_nmi_watchdog() and touch_all_softlockup_watchdogs(). current printk-kthread patch set tries to consider those cases and to avoid any offloading. -ss