Messages in this thread | | | Date | Tue, 2 Jun 2015 17:46:28 +0800 | From | "long.wanglong" <> | Subject | Re: [PATCH 00/10] printk: Avoid deadlock in NMI + vprintk_emit() cleanup |
| |
On 2015/6/1 21:06, Jan Kara wrote: > On Fri 29-05-15 13:50:45, Andrew Morton wrote: >> On Mon, 25 May 2015 14:46:23 +0200 Petr Mladek <pmladek@suse.cz> wrote: >> >>> The main source of deadlocks caused by printk() in NMI context has been >>> solved by the commit a9edc88093287 ("x86/nmi: Perform a safe NMI stack >>> trace on all CPUs"). >>> >>> But there are still few warnings printed in the NMI code that could >>> case a deadlock. For example, see the freeze discussed at >>> https://lkml.org/lkml/2015/5/20/481 >> >> I'm not (yet) convinced that we want the entire patchset btw. Do we >> really want to try to semi-support printk from NMI? With a rather >> nasty set of hacks? >> >> Why not just delete the offending printks? > And what about WARN_ONs and BUG_ONs? Delete as well? Or just don't print > anything when we are in NMI? I agree that NMI is so problematic context > that restricting printk there makes some sence. OTOH propagating > information from NMI to user is useful as well so I'm somewhat undecided. > > Honza >
I think that delete all printks in NMI context is not a good solution. because some information is very useful to user.
The commit a9edc88093287 ("x86/nmi: Perform a safe NMI stack trace on all CPUs") solved the deadlock problem only in arch_trigger_all_cpu_backtrace_handler() by replacing the printk to a special print function (nmi_vprintk). But all the other NMI handlers still use the original printk.
How about replacing printk function earlier? we can replace printk function before we calling default_do_nmi(arch/x86/kernel/nmi.c) and replace back after calling.
Is it a feasible solution? or does it introduce other problems?
Best Regards Wang Long
| |