From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id c9MnI9JWt2glkhIAWB0awg (envelope-from ) for ; Tue, 02 Sep 2025 16:42:58 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=lists.lttng.org header.i=@lists.lttng.org header.a=rsa-sha256 header.s=default header.b=eT+Z2YYd; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7BBF61E087; Tue, 02 Sep 2025 16:42:58 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Received: from lists.lttng.org (lists.lttng.org [158.69.130.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id AF4E41E057 for ; Tue, 02 Sep 2025 16:42:57 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGd3j24rkz1Bv4 ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1756845777; b=MSE1iKcgKVXhbHSXPXVnF5LJGG8dq861O99EOZdvXOpXQdfCz6fZLvSGS5VyTVzRPLN4 ZyxSb8vpOeuUKU8OiP5WK6ux97JEWhC37B511fNp8RE9CwO9qo/OzcasWMAG8TzlctYKx xhTSo1y5qMZPa6s5iH2ldqhhQd31J4m0m1I2i/0/WpzqEJFL1+t6MlWMAhywvNOq9+h+8 Zi84m9CCGo9sIRu1PRIcsV5eb6HM16W3Ev89ffaD6hoBulDsGvNIce5jibR72q88eHT8w I2WywNN8t3LcAqFvzM/tgb8GmI7HmB92pSL5Ic1wmhknE6MaAmgmXgOWwRjMKR9XzTQ== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1756845777; h=DKIM-Signature:Date:To:Subject:Message-ID:MIME-Version:From:From; bh=RN7qWmGsDd0NNhr32oFdWr0DHQIJ+zmsTxdS0ijCSSc=; b=joArwgdcDBeYsVH99gN2bCmltOKz0M1Kchqx3mZg/VUNFqI8iwpuMyNlIFJmng7afy/0 HbIJ2mmmO/uSxclNU2Q0PtKwIpPgoTwXu1Lxp7a0itgb6hCPSTsnH3hN1Enlu+0+5o+51 IQh7BIBxgtpZq+vgfFf8qwww4p6ukOKzLP1CVNw4CTJEk4plp40CE0dMsvOPjvLkMhu0u UeQs2pJNXZdsvLVmQzGij3PmhW074k+wMTVMpokeDWCbXo6dME2jva4CL1KY4WyrLwdMn Aj87NgeAKTDsKFD61BZFFavAAn+lr4LdgmNTq0qJXJJdUqMTIxFSyBG/hNVivywtGQw== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGd3j24rkz1Bv4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1756845777; bh=RN7qWmGsDd0NNhr32oFdWr0DHQIJ+zmsTxdS0ijCSSc=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=eT+Z2YYdbt4GkETc6RYaAG0/jOmDSF3tQt4t7G138JMszn649D+6CwZLkArqw7s+Z CAhF39Uw3e16o7FX5jxDQO42zD33/lRYqXapdqmYh++YB2dzCQ45UhFF1JSy4qAwGI UZyREgo2DFIMNPeK+06yQrPxQP3KdyjJuoIiMjPeCPmVNFNL9okWnPm0Gl+nieJ2DR aqNesEvN3AOPFz7wm6/YrgJBPd9uYR23WraERm+02om9Ws3c1nlmtioyFSO0cLPxvT I77RphTUzssl1EbJCLs5W0Yl2XtdA3BiKIpK97A1cR0XSFih/RpH6q+GipNOIUrSva J40h3+kcogWpw== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cGd3j24rkz1Bv4; Tue, 2 Sep 2025 16:42:57 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGd3h0wMrz1Bls DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGd3h0wMrz1Bls Received: from tor.source.kernel.org (tor.source.kernel.org [IPv6:2600:3c04:e001:324:0:1991:8:25]) by lists.lttng.org (Postfix) with ESMTPS id 4cGd3h0wMrz1Bls for ; Tue, 2 Sep 2025 16:42:55 -0400 (EDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id BC36360097; Tue, 2 Sep 2025 20:33:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70916C4CEED; Tue, 2 Sep 2025 20:33:28 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 1CA7BCE0C15; Tue, 2 Sep 2025 13:33:28 -0700 (PDT) Date: Tue, 2 Sep 2025 13:33:28 -0700 To: Thobias Knudsen Subject: Re: URCU feature request? Message-ID: <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Paul E. McKenney via lttng-dev" Reply-To: paulmck@kernel.org Cc: Olivier Dion , lttng-dev@lists.lttng.org Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" On Tue, Sep 02, 2025 at 04:24:16PM +0200, Thobias Knudsen wrote: > Figured out what rcu_read_ongoing does. It just returns true if it's called > within a read section and false otherwise. The problem for catching whether > reads are done outside read sections is that you can not make macros for > read and write operations. e.g. ptr->a = 4;. We usually rely on the debugging code in rcu_dereference() to check this sort of thing. Or are you worried about the user leaking RCU-protected pointers out past the rcu_read_unlock()? Thanx, Paul > tir. 2. sep. 2025 kl. 16:17 skrev Thobias Knudsen : > > > > I suspect that what you are trying to achieve is validation that > > > calls to functions that require to be within a RCU read-side critical > > > section such as cds_lfht_lookup are indeed invoked from within a > > > critical section. > > > > Yes exactly, but not only for read sections. It could also be to validate > > that rcu_barrier isnt called within a callback function or that > > rcu_quiescent_state isnt called when thread is offline > > > > > We've added a "rcu_read_ongoing()" API for that purpose to liburcu > > > RCU flavors, but AFAIK it's not used for any kind of validation > > > within cds_lfht. This could indeed become a feature request that > > > would apply to all liburcu data structure APIs. > > > > I can't find any documentation on rcu_read_ongoing. Btw the documentation > > for urcu in general is scattered all around the repo it seems. It should > > have been all at one place imo. Should I make a feature request for it? I > > don't know how stuff works inside this repo though. > > > > > > > > man. 1. sep. 2025 kl. 17:09 skrev Mathieu Desnoyers < > > mathieu.desnoyers@efficios.com>: > > > >> On 2025-08-31 16:48, Thobias Knudsen wrote: > >> > BTW i've made a macro library which overrides the > >> > urcu and lfht functions. It checks that you call the functions in the > >> > correct order. This has been really useful for debugging and I think it > >> > would be useful to have it integrated into urcu to make the it more > >> user > >> > friendly. you could have it integrated with the macro DEBUG_RCU or make > >> > a new one, maybe DEBUG_FUNCTION_CALL_ORDER. The only thing it doesn't > >> > catch is if you continue to use data from cds_lfht_lookup() after > >> > rcu_read_unlock() > >> > >> I suspect that what you are trying to achieve is validation that > >> calls to functions that require to be within a RCU read-side critical > >> section such as cds_lfht_lookup are indeed invoked from within a > >> critical section. > >> > >> We've added a "rcu_read_ongoing()" API for that purpose to liburcu > >> RCU flavors, but AFAIK it's not used for any kind of validation > >> within cds_lfht. This could indeed become a feature request that > >> would apply to all liburcu data structure APIs. > >> > >> Thanks, > >> > >> Mathieu > >> > >> > > >> > søn. 31. aug. 2025 kl. 22:42 skrev Thobias Knudsen >> > >: > >> > > >> > First question: why isn't Userspace RCU more popular? > >> > Second question: Why isn't it possible to create issues in the urcu > >> > repo? Im asking for a feature here: > >> > Is it possible to make a function which checks if there are more > >> > callbacks queued by call_rcu? I need that because there are some > >> > callbacks which call call_rcu, and then calling rcu_barrier once > >> > isn't enough and I therefore need a way to check if there are still > >> > callbacks to wait on before terminating the program. No worries if > >> > this is too much to ask for or if it isn't possible. This > >> > functionality is only needed in termination because otherwise > >> > isn't needed to call rcu_barrier multiple times (at least so far) > >> > > >> > Best regards > >> > Thobias > >> > > >> > > >> > >> > >> -- > >> Mathieu Desnoyers > >> EfficiOS Inc. > >> https://www.efficios.com > >> > >