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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 994CCC433EF for ; Thu, 21 Apr 2022 13:34:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A1226B0072; Thu, 21 Apr 2022 09:34:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 050896B0073; Thu, 21 Apr 2022 09:34:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5A176B0074; Thu, 21 Apr 2022 09:34:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id D5E076B0072 for ; Thu, 21 Apr 2022 09:34:18 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AC5A863620 for ; Thu, 21 Apr 2022 13:34:18 +0000 (UTC) X-FDA: 79380980196.14.CBFB754 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf18.hostedemail.com (Postfix) with ESMTP id 49C3D1C001C for ; Thu, 21 Apr 2022 13:34:16 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 76CB3B8229C; Thu, 21 Apr 2022 13:34:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2628C385A8; Thu, 21 Apr 2022 13:34:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650548055; bh=XhJaTQ5MBxvR+RRnElyRh1/59M5G2XlaZ5GXZhUhBIo=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=osEcRBbwr3csqc2gnWy9/uk5f07YOSnU4isnwGtRW5vpw09OOJrIGvyOmJVa2PMnT FYkiNRaEY6xuCg7dpK95rCCZdb3VEUQapjnSy6hnqAmjDiy/5q8MN2uWx5+UsSdAe2 W9PnoQp0w8Ve+U5ru0flt8yclsE+C6ywgclDfDjPQp19qkqrvaBxpoLKoKroI2Drjq LbOJxUM/fUN2ma9o+xZdHggWoK750+3ZEK+FubWC+WMF3XX4GQ3bjiEfrcRX1s5uWT 4o7s57zAlHdtKMvwLbgxdzn4eDKzlncIXlUufu081nc9ezf/mwjaYiAjepFxAUsYFM J6bLQtnVDzUfg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 7F6315C0143; Thu, 21 Apr 2022 06:34:14 -0700 (PDT) Date: Thu, 21 Apr 2022 06:34:14 -0700 From: "Paul E. McKenney" To: Hillf Danton Cc: Sean Christopherson , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [Question] srcu: is it making sense to recursively invoke srcu_read_lock? Message-ID: <20220421133414.GP4285@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <20220421042211.2433-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220421042211.2433-1-hdanton@sina.com> X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 49C3D1C001C X-Stat-Signature: b6jd3jf56xmca7yp87nethde9jppg47u Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=osEcRBbw; spf=pass (imf18.hostedemail.com: domain of "SRS0=OQHl=U7=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=OQHl=U7=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1650548056-290160 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 21, 2022 at 12:22:11PM +0800, Hillf Danton wrote: > Given rcu_lock_acquire() in srcu_read_lock(), > > iA = srcu_read_lock(foo); > iB = srcu_read_lock(foo); // not bar > ... > srcu_read_unlock(foo, iB); > srcu_read_unlock(foo, iA); > > can the call sequence above trigger warning with CONFIG_DEBUG_LOCK_ALLOC enabled? I hope not! After all, nesting SRCU read-side critical sections is perfectly legal. But why not just try it and see? > Does it make sense to add srcu_lock_acquire() in line with rwsem_acquire_read() if > warning is expected but not triggered? Please understand that while SRCU can often be used where an rwsem might otherwise be used, SRCU is not an rwsem. For one thing, rwsem readers can deadlock in ways that SRCU reader cannot. Now, I don't yet know of a non-destructive use case for partially overlapping SRCU read-side critical sections, for example, if you switched the two srcu_read_unlock() calls above. But at the same time, I cannot prove that there is no valid use case, not yet, anyway. Thanx, Paul > Thanks > Hillf > > static inline void rcu_lock_acquire(struct lockdep_map *map) > { > lock_acquire(map, 0, 0, 2, 0, NULL, _THIS_IP_); > } > > static inline void srcu_lock_acquire(struct lockdep_map *map) > { > lock_acquire(map, 0, 0, 1, 0, NULL, _THIS_IP_); > }