From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752583AbcI3L1w (ORCPT ); Fri, 30 Sep 2016 07:27:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:46570 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751099AbcI3L1p (ORCPT ); Fri, 30 Sep 2016 07:27:45 -0400 Date: Fri, 30 Sep 2016 13:27:43 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Jan Kara , Andrew Morton , Tejun Heo , Calvin Owens , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 0/7] printk: use alt_printk to handle printk() recursive calls Message-ID: <20160930112743.GJ26796@pathway.suse.cz> References: <20160927142237.5539-1-sergey.senozhatsky@gmail.com> <20160929132502.GG26796@pathway.suse.cz> <20160930024307.GE547@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160930024307.GE547@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 Fri 2016-09-30 11:43:07, Sergey Senozhatsky wrote: > On (09/29/16 15:25), Petr Mladek wrote: > > On Tue 2016-09-27 23:22:30, Sergey Senozhatsky wrote: > > > Hello, > > > > > > RFC > > > > > > This patch set extends a lock-less NMI per-cpu buffers idea to > > > handle recursive printk() calls. The basic mechanism is pretty much the > > > same -- at the beginning of a deadlock-prone section we switch to lock-less > > > printk callback, and return back to a default printk implementation at the > > > end; the messages are getting flushed to a logbuf buffer from a safer > > > context. > > > > I was skeptical but I really like this way now. > > > > The switching of the buffers is a bit hairy in this version but I > > think that we could make it much better. > > > > Other than that it looks like a big win. It kills a lot of > > printk-related pain points. And it will not be that complicated > > after all. > > many thanks for looking at this train wreck. > > so, like I said, it addresses printk()-recursion in *ideally* quite > a minimalistic way -- just several alt_printk_enter/exit calls in > printk.c, without ever touching any other parts of the kernel. > > gunning down printk deadlocks in general, however, requires much more > effort; or even a completely different approach. > > a) a lock-less printk() by default > um, `#define printk alt_printk'. but this will break printk() from irq. > and the ordering of messages from per-cpu buffers may be far from correct. Well, the current vprintk_nmi() is lockless. The alternative printk() is going to use the same code, so it will be lockless as well. It means that even this patchset is supposed to avoid all possible deadlocks via printk() calls. There is still a risk of an infinite recursion. But vprintk_nmi() bails out early when the buffer is full. This should minimalize the risk. In fact, the recursion would become rather theoretical problem. Best Regards, Petr