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 31FE3C433F5 for ; Fri, 22 Apr 2022 00:52:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4321C6B0072; Thu, 21 Apr 2022 20:52:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B9B96B0073; Thu, 21 Apr 2022 20:52:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 259886B0074; Thu, 21 Apr 2022 20:52:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 135146B0072 for ; Thu, 21 Apr 2022 20:52:28 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id D215860749 for ; Fri, 22 Apr 2022 00:52:27 +0000 (UTC) X-FDA: 79382689134.23.12C0814 Received: from r3-20.sinamail.sina.com.cn (r3-20.sinamail.sina.com.cn [202.108.3.20]) by imf25.hostedemail.com (Postfix) with SMTP id 7D844A0002 for ; Fri, 22 Apr 2022 00:52:22 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.249.57.134]) by sina.com (172.16.97.35) with ESMTP id 6261FC3500032FBB; Fri, 22 Apr 2022 08:52:07 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 61427615073933 From: Hillf Danton To: "Paul E. McKenney" 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? Date: Fri, 22 Apr 2022 08:52:12 +0800 Message-Id: <20220422005212.2569-1-hdanton@sina.com> In-Reply-To: <20220421133414.GP4285@paulmck-ThinkPad-P17-Gen-1> References: <20220421042211.2433-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 7D844A0002 X-Stat-Signature: qesekupb7hsb6up4im9rq8sjc4mypc69 Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.20 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-Rspamd-Server: rspam01 X-HE-Tag: 1650588742-52018 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, 21 Apr 2022 06:34:14 -0700 Paul E. McKenney wrote: > 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? Thanks for shedding light on nested SRCUs - it cures my pain working out the reason for how detecting nested SRCUs is added [1]. Now I see why it is out of kernel/rcu. Hillf [1] https://lore.kernel.org/lkml/20220415004343.2203171-4-seanjc@google.com/ > > 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_); > > } >