From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933775AbcBCIEx (ORCPT ); Wed, 3 Feb 2016 03:04:53 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36262 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933161AbcBCIEv (ORCPT ); Wed, 3 Feb 2016 03:04:51 -0500 Date: Wed, 3 Feb 2016 09:04:47 +0100 From: Ingo Molnar To: Sergey Senozhatsky Cc: Byungchul Park , willy@linux.intel.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, akinobu.mita@gmail.com, jack@suse.cz, peter@hurleysoftware.com, Linus Torvalds Subject: Re: [PATCH v2] lock/semaphore: Avoid an unnecessary deadlock within up() Message-ID: <20160203080447.GC32652@gmail.com> References: <1454479377-24434-1-git-send-email-byungchul.park@lge.com> <20160203072847.GA32026@gmail.com> <20160203074223.GB30520@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160203074223.GB30520@swordfish> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Sergey Senozhatsky wrote: > On (02/03/16 08:28), Ingo Molnar wrote: > [..] > > So why not move printk away from semaphores? Semaphores are classical constructs > > that have legacies and are somewhat non-obvious to use, compared to modern, > > simpler locking primitives. I'd not touch their implementation, unless we are > > absolutely sure this is a safe optimization. > > semaphore's spin_lock is not the only spin lock that printk acquires. it also > takes the logbuf_lock (and different locks in console drivers (up to console > driver)). > > Jan Kara posted a patch that offloads printing job > (console_trylock()-console_unlock()) from printk() call (when printk can offload > it). so semaphore and console driver's locks will go away (mostly) with Jan's > patch. logbug spin_lock, however, will stay. Well, but this patch of yours only affects the semaphore code, so it does not change the logbuf_lock situation. Furthermore, logbuf_lock already has recursion protection: /* * Ouch, printk recursed into itself! */ if (unlikely(logbuf_cpu == this_cpu)) { so it should not be possible to re-enter the printk() logbuf_lock critical section from the spinlock code. (There are other ways to get the logbuf_lock - if those are still triggerable then they should be fixed.) In any case, recursion protection is generally done in the debugging facilities trying to behave lockless. Thanks, Ingo