From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758683AbcHaCba (ORCPT ); Tue, 30 Aug 2016 22:31:30 -0400 Received: from mail-pa0-f66.google.com ([209.85.220.66]:36174 "EHLO mail-pa0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758393AbcHaCb1 (ORCPT ); Tue, 30 Aug 2016 22:31:27 -0400 Date: Wed, 31 Aug 2016 11:31:35 +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: <20160831023134.GA390@swordfish> References: <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> <20160825210959.GA2273@dhcp128.suse.cz> <20160826015641.GA520@swordfish> <20160830092912.GP4866@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160830092912.GP4866@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/30/16 11:29), Petr Mladek wrote: > > you didn't miss anything, I think I wasn't too descriptive and that caused > > some confusion. this patch is not a replacement of wake_up_process() patch > > posted earlier in the loop, but an addition to it. not only every WARN/BUG > > issued from wake_up_process() will do no good, but every lock we take is > > potentially dangerous as well. In the simplest case because of $LOCK-debug.c > > files in kernel/locking (spin_lock in our case); in the worst case -- > > because of WARNs issued by log_store() and friends (there may be custom > > modifications) or by violations of spinlock atomicity requirements. > > > > For example, > > > > vprintk_emit() > > local_irq_save() > > raw_spin_lock() > > text_len = vscnprintf(text, sizeof(textbuf), fmt, args) > > { > > vsnprintf() > > { > > if (WARN_ON_ONCE(size > INT_MAX)) > > return 0; > > } > > } > > ... > > > > this is a rather unlikely event, sure, there must be some sort of > > memory corruption or something else, but the thing is -- if it will > > happen, printk() will not be willing to help. > > > > wake_up_process() change, posted earlier, is using a deferred version of > > WARN macro, but we definitely can (and we better do) switch to lockless > > alternative printk() in both cases and don't bother with new macros. > > replacing all of the existing ones with 'safe' deferred versions is > > a difficult task, but keeping track of a newly introduced ones is even > > harder (if possible at all). > > I see. It makes some sense. I would like to be on the safe side. I am > just afraid that adding yet another per-CPU buffer is too complex. > It adds quite some complexity to the code. And it even more scatters > the messages so that it will be harder to get them from the > crash dump or flush them to the console when the system goes down. > > It took few years to get in the solution for NMIs even when > it fixed real life deadlocks for many people and customers. > I am afraid that it is not realistic to get in similar complex > code to fix rather theoretical problems. well, I still can try it in my spare time. we can't fix printk() without ever touching it, can we? so far we basically only acknowledge the existing printk() problems. we can do better than that, I think. > Sigh, I waited few days with this comment. I do not want to sound > like a broken record. no worries -ss