From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751368AbcDXERL (ORCPT ); Sun, 24 Apr 2016 00:17:11 -0400 Received: from mail-pf0-f169.google.com ([209.85.192.169]:36431 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750711AbcDXERK (ORCPT ); Sun, 24 Apr 2016 00:17:10 -0400 Date: Sun, 24 Apr 2016 14:14:49 +0900 From: Sergey Senozhatsky To: Pavel Machek Cc: Jan Kara , Sergey Senozhatsky , Andrew Morton , Jan Kara , Petr Mladek , Tejun Heo , Tetsuo Handa , linux-kernel@vger.kernel.org, Byungchul Park , Sergey Senozhatsky Subject: Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async Message-ID: <20160424051449.GB587@swordfish> References: <1458581130-8677-1-git-send-email-sergey.senozhatsky@gmail.com> <20160322064948.GA4459@quack.suse.cz> <20160423194019.GB15755@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160423194019.GB15755@amd> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (04/23/16 21:40), Pavel Machek wrote: [..] > > > The patch set is against next-20160321 > > > > > > the series in total has 3 patches: > > > - printk: Make printk() completely async > > > - printk: Make wake_up_klogd_work_func() async > > > - printk: make console_unlock() async > > > > > > per discussion, "printk: make console_unlock() async" will be posted > > > later on. > > > > Patches look good to me. I don't think you need to mention the > > console_unlock() async patch when it is not part of the series. BTW, you > > seemed to have dropped my patch to skip if there are too many buffered > > messages when oops is in progress. Any reason for that? > > So... from basically linux 0.0, cli() printk("") could be used for > debugging. ... and that's now gone. Right? > > Can you explain why that is good idea? it's not gone. you need to explicitly enable async printk mode. the case you mentioned -- cli() printk("")->console_unlock() -- apart from being useful in some scenarios, can cause problems in others, simply because under some circumstances it can run forever, as long as there are printk() calls coming from other CPUs (which can happen during, f.e., debugging). did you mean UP systems? well, async printk is sort of useless on UP systems anyway. -ss