From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935654AbcI3CBC (ORCPT ); Thu, 29 Sep 2016 22:01:02 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:36100 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935345AbcI3CAy (ORCPT ); Thu, 29 Sep 2016 22:00:54 -0400 Date: Fri, 30 Sep 2016 11:00:45 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Jan Kara , Andrew Morton , Tejun Heo , Calvin Owens , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCH 7/7] printk: new printk() recursion detection Message-ID: <20160930020045.GD547@swordfish> References: <20160927142237.5539-1-sergey.senozhatsky@gmail.com> <20160927142237.5539-8-sergey.senozhatsky@gmail.com> <20160929131958.GF26796@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160929131958.GF26796@pathway.suse.cz> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (09/29/16 15:19), Petr Mladek wrote: > I am sorry but I do not understand this much. printk() should set the > alternative implementation in the critical section by default. > Why do we need to handle this so specially? > > Is it because of flushing in NMI context when panicing? I would call > vprintk_emit() directly from the flush_line() function in this case. > Then all other possible error printk's will get redirected to the > NMI buffer which is good enouh. I'm going to re-do the entire thing. I had some cases in mind, like WARN from vsnprintf from printk from alt_printk_flushing from panic. or something like this. perhaps too complicated, will re-think it. -ss