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 623E1C433EF for ; Fri, 22 Apr 2022 03:09:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C98316B0072; Thu, 21 Apr 2022 23:09:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C20276B0073; Thu, 21 Apr 2022 23:09:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9AD56B0074; Thu, 21 Apr 2022 23:09:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 97B406B0072 for ; Thu, 21 Apr 2022 23:09:49 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6E01F23C6C for ; Fri, 22 Apr 2022 03:09:49 +0000 (UTC) X-FDA: 79383035298.22.5D4DBA2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id 87553C000D for ; Fri, 22 Apr 2022 03:09:45 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 3820B61BB8; Fri, 22 Apr 2022 03:09:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E221C385A5; Fri, 22 Apr 2022 03:09:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650596987; bh=MUjn2eDyj/XfXhTCseYbBBOb69CJ6G25z9lQyp5keeQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=c2amM5S0hr0LEeseyj/W2hNLhw5omUH6BRlFKGI1h0AXMwRqo/I5EOw300ReIqJXH yO041iG7WLAQTnXfvJbju1twC9HJCmciI29+FOotq+H/p/d9xvT2USG/t5Ua5Wa4uH XL/ZrCmKBt9YShfNzYLQFgieMNY2p3xqcwiJQTA7o8Awp7KG7P21zCHlDrZrLmdc+w 6hZj5bCdxVH/+kT4DJ38L1QzcEyV0Trw9YuSnU+z0rDxUB4D+bHvjuezYlo/5VS/5t D+5toAifNYrjSWIiQMNC/DmGJlSkGsUtIvOYidmg2l1c8kpvaygK6ijyLm1WGAiccj 8nYNt5j0gYkfQ== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 3B4C25C0513; Thu, 21 Apr 2022 20:09:47 -0700 (PDT) Date: Thu, 21 Apr 2022 20:09:47 -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: <20220422030947.GT4285@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <20220421042211.2433-1-hdanton@sina.com> <20220422005212.2569-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220422005212.2569-1-hdanton@sina.com> Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=c2amM5S0; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of "SRS0=I3Nv=VA=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=I3Nv=VA=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 87553C000D X-Stat-Signature: qmk8enpsjajap8ryazcfqt3ehjib1cey X-HE-Tag: 1650596985-447080 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 Fri, Apr 22, 2022 at 08:52:12AM +0800, Hillf Danton wrote: > 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. Just to be clear... If the KVM guys want to impose a design rule that SRCU read-side critical sections never be nested within their code, that is a perfectly reasonable thing for them to do. Thanx, Paul > 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_); > > > } > >