From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758196AbcH3LTx (ORCPT ); Tue, 30 Aug 2016 07:19:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:59101 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757470AbcH3LTw (ORCPT ); Tue, 30 Aug 2016 07:19:52 -0400 Date: Tue, 30 Aug 2016 13:19:48 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Andrew Morton , Jan Kara , linux-kernel@vger.kernel.org Subject: Re: [PATCH] printk/nmi: avoid direct printk()-s from __printk_nmi_flush() Message-ID: <20160830111948.GQ4866@pathway.suse.cz> References: <20160829123220.1295-1-sergey.senozhatsky@gmail.com> <20160829151600.GM4866@pathway.suse.cz> <20160830075834.GA494@swordfish> <20160830090436.GO4866@pathway.suse.cz> <20160830093918.GA23693@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160830093918.GA23693@swordfish> 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 On Tue 2016-08-30 18:39:18, Sergey Senozhatsky wrote: > On (08/30/16 11:04), Petr Mladek wrote: > > On Tue 2016-08-30 16:58:34, Sergey Senozhatsky wrote: > > > Petr, > > > one more question. Not related to the patch, but still related to NMI. > > > > > > can NMI nest? > > > > AFAIK, they cannot. NMIs should be disabled until iret is called. > > Therefore we should be on the safe side if iret is not called > > inside the NMI handler. But this should not happen because > > it would cause other problems, like using wrong return address. > > > > Well, x86 nmi code has some hacks to handle exceptions inside > > NMI handlers that use iret. But printk_nmi_enter()/printk_nmi_exit() > > are never nested there. It is prevented by the nmi_state per-CPU > > variable. See do_nmi() in arch/x86/kernel/nmi.c. > > yes, x86 has a per-cpu nmi_state to handle the case when NMI is > loosing its NMI context. But other arch-s, as far as I can see, > don't do that. Does it mean that we are safe only on x86? My understanding is that the kernel would crash on the other architectures if a double iret was called. By other words, they would have bigger problems than the nmi_enter()/nmi_exit() calls. So, we should be on the safe side. > this printk_func_saved thing is still will be needed, I think, > for alt_printk. > > Example: > > process abc > printk() > alt_printk_enter() > this_cpu_write(printk_func, vprintk_alt); > -> NMI > : printk_nmi_enter() > : this_cpu_write(printk_func, vprintk_nmi); > : printk_nmi_exit() > : this_cpu_write(printk_func, vprintk_default); > return NMI > > printk() <<<< nested printk -> vprintk_default(), set by nmi_exit() > alt_printk_exit() > ... I see. But then we will need to be more careful because printk_func and printk_func_saved will be manipulated in different contexts: normal, irq, nmi. A solution might be using an atomic counter and selecting the right vprintk_func according to the value. Well, I am still afraid that yet another alt_printk is not the way to go. Best Regards, Petr