Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9711BC54EAA for ; Thu, 26 Jan 2023 19:10:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232431AbjAZTKP (ORCPT ); Thu, 26 Jan 2023 14:10:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229777AbjAZTKM (ORCPT ); Thu, 26 Jan 2023 14:10:12 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 8DFE7190 for ; Thu, 26 Jan 2023 11:10:11 -0800 (PST) Received: (qmail 273220 invoked by uid 1000); 26 Jan 2023 14:10:10 -0500 Date: Thu, 26 Jan 2023 14:10:10 -0500 From: Alan Stern To: "Paul E. McKenney" Cc: Jonas Oberhauser , Andrea Parri , Jonas Oberhauser , Peter Zijlstra , will , "boqun.feng" , npiggin , dhowells , "j.alglave" , "luc.maranget" , akiyks , dlustig , joel , urezki , quic_neeraju , frederic , Kernel development list Subject: Re: [Patch 2/2] tools/memory-model: Provide exact SRCU semantics Message-ID: References: <20230126173507.GE2948950@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230126173507.GE2948950@paulmck-ThinkPad-P17-Gen-1> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 26, 2023 at 09:35:07AM -0800, Paul E. McKenney wrote: > On Thu, Jan 26, 2023 at 12:30:14PM +0100, Jonas Oberhauser wrote: > > I don't think they're necessarily implemented in a compatible way, so > > > > r = srcu_lock(s); > > srcu_up(s,r); > > > > might not actually work, but would currently be ok'ed by LKMM. > > In kernels built with CONFIG_PROVE_LOCKING=y (AKA built with lockdep > enabled), lockdep would complain about having an srcu_read_lock() with > no matching srcu_read_unlock(). Kernels built without lockdep (that is, > kernels actually used in production) would be happy with this. > > So as Jonas suspects, this should be classified as not actually working. Lockdep complaints don't actually stop things from working (unless you want them to). They're just warnings, right? Alan