From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03FC7C4332D for ; Thu, 19 Mar 2020 15:24:42 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 63E6520658 for ; Thu, 19 Mar 2020 15:24:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 63E6520658 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lwn.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 48jrLG0nbNzDr02 for ; Fri, 20 Mar 2020 02:24:38 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lwn.net (client-ip=45.79.88.28; helo=ms.lwn.net; envelope-from=corbet@lwn.net; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=lwn.net Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 48jqv52s08zDqG6 for ; Fri, 20 Mar 2020 02:04:32 +1100 (AEDT) Received: from lwn.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id DB45F384; Thu, 19 Mar 2020 15:04:27 +0000 (UTC) Date: Thu, 19 Mar 2020 09:04:26 -0600 From: Jonathan Corbet To: Thomas Gleixner Subject: Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation Message-ID: <20200319090426.512510cb@lwn.net> In-Reply-To: <20200318204408.211530902@linutronix.de> References: <20200318204302.693307984@linutronix.de> <20200318204408.211530902@linutronix.de> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Randy Dunlap , Peter Zijlstra , linux-pci@vger.kernel.org, Sebastian Andrzej Siewior , Oleg Nesterov , Joel Fernandes , Will Deacon , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , Logan Gunthorpe , "Paul E . McKenney" , linuxppc-dev@lists.ozlabs.org, Steven Rostedt , Bjorn Helgaas , Kurt Schwemmer , Kalle Valo , Felipe Balbi , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, LKML , netdev@vger.kernel.org, Linus Torvalds , "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, 18 Mar 2020 21:43:10 +0100 Thomas Gleixner wrote: > From: Thomas Gleixner > > The kernel provides a variety of locking primitives. The nesting of these > lock types and the implications of them on RT enabled kernels is nowhere > documented. > > Add initial documentation. ...time to add a a couple of nits...:) > Signed-off-by: Thomas Gleixner > --- > V2: Addressed review comments from Randy > --- > Documentation/locking/index.rst | 1 > Documentation/locking/locktypes.rst | 298 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 299 insertions(+) > create mode 100644 Documentation/locking/locktypes.rst > > --- a/Documentation/locking/index.rst > +++ b/Documentation/locking/index.rst > @@ -7,6 +7,7 @@ locking > .. toctree:: > :maxdepth: 1 > > + locktypes > lockdep-design > lockstat > locktorture > --- /dev/null > +++ b/Documentation/locking/locktypes.rst > @@ -0,0 +1,298 @@ > +.. _kernel_hacking_locktypes: > + So ... I vaguely remember that some Thomas guy added a document saying we should be putting SPDX tags on our files? :) > +========================== > +Lock types and their rules > +========================== [...] > +PREEMPT_RT caveats > +================== > + > +spinlock_t and rwlock_t > +----------------------- > + > +The substitution of spinlock_t and rwlock_t on PREEMPT_RT enabled kernels > +with RT-mutex based implementations has a few implications. > + > +On a non PREEMPT_RT enabled kernel the following code construct is > +perfectly fine:: > + > + local_irq_disable(); > + spin_lock(&lock); > + > +and fully equivalent to:: > + > + spin_lock_irq(&lock); > + > +Same applies to rwlock_t and the _irqsave() suffix variant. > + > +On a PREEMPT_RT enabled kernel this breaks because the RT-mutex > +substitution expects a fully preemptible context. > + > +The preferred solution is to use :c:func:`spin_lock_irq()` or > +:c:func:`spin_lock_irqsave()` and their unlock counterparts. We don't need (and shouldn't use) :c:func: anymore; just saying spin_lock_irq() will cause the Right Things to happen. Thanks, jon