From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755587AbcHXBeB (ORCPT ); Tue, 23 Aug 2016 21:34:01 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:35138 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755184AbcHXBd6 (ORCPT ); Tue, 23 Aug 2016 21:33:58 -0400 Date: Wed, 24 Aug 2016 10:33:14 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Jan Kara , Sergey Senozhatsky , Viresh Kumar , Andrew Morton , Jan Kara , Tejun Heo , Tetsuo Handa , "linux-kernel@vger.kernel.org" , Byungchul Park , vlevenetz@mm-sol.com, Greg Kroah-Hartman Subject: Re: [PATCH v10 1/2] printk: Make printk() completely async Message-ID: <20160824013314.GB452@swordfish> References: <20160818022712.GB500@swordfish> <20160818093329.GL13300@pathway.suse.cz> <20160818095144.GA425@swordfish> <20160818105629.GE26194@pathway.suse.cz> <20160819063236.GA584@swordfish> <20160819095455.GR13300@pathway.suse.cz> <20160819190007.GA8275@quack2.suse.cz> <20160820052430.GA695@swordfish> <20160822041520.GA511@swordfish> <20160823121903.GD4866@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160823121903.GD4866@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 (08/23/16 14:19), Petr Mladek wrote: > > the other thing I just thought of is doing something as follows > > !!!not tested, will not compile, just an idea!!! > > > > --- > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > > index 6e260a0..bb8d719 100644 > > --- a/kernel/printk/printk.c > > +++ b/kernel/printk/printk.c > > @@ -1789,6 +1789,7 @@ asmlinkage int vprintk_emit(int facility, int level, > > printk_delay(); > > > > local_irq_save(flags); > > + printk_nmi_enter(); > > this_cpu = smp_processor_id(); > > Huh, this looks very interesting but I am afraid that it will not fly. > The problem is that vprintk_nmi() is safe only when it is used > exclusively in NMI. > > The following could happen with your code: sure. I took NMI as a quick and easy example that did not require a lot of words to explain because you guys are familiar with NMI printing. the thing is - we don't have to share the same buffer with the actual NMI, but instead have our own small 'alternative-printk' per-cpu buffers (a page or two, perhaps). it's up to `printk_func' that we set up at the entry point and flush function that we execute later. vprintk_nmi() writes to this_cpu_ptr(&nmi_print_seq), vprintk_alter() will write to this_cpu_ptr(&alt_print_seq), for example. the same with flushing: printk_nmi_flush reads in from per_cpu(nmi_print_seq); alter-printk flush can read from per_cpu(alt_print_seq). [..] > The lockless handling of the NMI per-CPU buffer already is not > trivial. I would be afraid to add more hacks to make > it writable in all contexts. yes. we can reuse the idea of NMI printk and most of the code. the thing we really care is `struct nmi_seq_buf' assigned to this particular CPU, and there can be several seq_buffer-s. > I am sorry about the bad news. This was so promising on the first > look. it's not dead yet ;) -ss