From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934854AbcCPG7i (ORCPT ); Wed, 16 Mar 2016 02:59:38 -0400 Received: from mail-pf0-f171.google.com ([209.85.192.171]:34503 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932575AbcCPG7g (ORCPT ); Wed, 16 Mar 2016 02:59:36 -0400 Date: Wed, 16 Mar 2016 15:58:51 +0900 From: Sergey Senozhatsky To: Byungchul Park Cc: Sergey Senozhatsky , Jan Kara , Andrew Morton , Jan Kara , Petr Mladek , Tejun Heo , Tetsuo Handa , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async Message-ID: <20160316065851.GC3217@swordfish> References: <1457964820-4642-1-git-send-email-sergey.senozhatsky@gmail.com> <1457964820-4642-2-git-send-email-sergey.senozhatsky@gmail.com> <20160315100323.GF17942@quack.suse.cz> <20160315140738.GA773@swordfish> <20160316053944.GJ5220@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160316053944.GJ5220@X58A-UD3R> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (03/16/16 14:39), Byungchul Park wrote: > On Tue, Mar 15, 2016 at 11:07:38PM +0900, Sergey Senozhatsky wrote: > > > > something like this (*minimally tested so far*). > > > > -- move wake_up() and friends under the logbuf section; so we can detect > ^^^^^^^^^^^^^^ > section protected by logbuf_lock? > > > printk() recursion from wake_up() > > Excuse me, but I fear that it can cause an unnecessary deadlock. where? shouldn't it be vprintk_emit() local_irq_save(flags); this_cpu = smp_processor_id(); raw_spin_lock(&logbuf_lock); static logbuf_cpu = this_cpu; wake_up_process() spin_lock() spin_dump() vprintk_emit() << recursion local_irq_save(flags); this_cpu = smp_processor_id(); if (unlikely(logbuf_cpu == this_cpu)) { recursion_bug = true; return; << break recursion } ? > Furthermore it cannot be handled if it is caused by logbuf_lock. sure, I'm not even trying to address a logbuf spin_dump recursion problem here. I'm only trying to minimize the impact of newly introduced spin locks. I don't have a very clear vision (at the moment) of how to fix printk recursion caused by logbuf lock of console_sem corruptions, etc. Should spin_dump be aware of the locks that can be taken by printk()? Hm, I can't even count all the locks that possibly can be taken by printk->console_drivers and most likely don't even see all of the cases where printk can recurse. Disable lock debug in vprintk_emit() the same way lockdep is desabled? Hm... Ingo's POV is that printk must be reworked and become smarter in this aspect. > I mean that it would be better to keep the wake_up and friend out of the > critical section by logbuf_lock. in this case wake_up_process() can recurse us forever. -ss