From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id adExIRYAt2hfPRIAWB0awg (envelope-from ) for ; Tue, 02 Sep 2025 10:32:54 -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=gcEOzFkE; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 825AA1E04C; Tue, 02 Sep 2025 10:32:54 -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,HTML_MESSAGE,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) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C0B5B1E043 for ; Tue, 02 Sep 2025 10:32:53 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGSrj0tYGz17HD ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1756823573; b=QQG8it07lStedA/biUquvCRaT2FUkTZyygQ//v3sFd+EBgaLypwEUC8wld60KyQjM2Uy Rtf2IE9ufq7NMAmrTi62j+oZ+YTM6VC8sUMD2acn4mstrSzfO2bepHCQLUsK4abBUje3l sx4H1BilG6H0MyagFe5Z8y9IQiT5LhibZWdlfV5UtdqzTgmURge2msJxNVfEMRQ62q+mb PMAGjrbSgrLavRNqg9lNJt0UgO7rmySuqgTcI0g0FG+3cbRhk/2gB/1EpHGjDmt4jlXbp 3iv43iGQ3d5Sylu821jsKL8wUlhpbQle05iSWcyn1bgFrFRVKJwIRYgw7FsVcs8xr7w== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1756823573; h=DKIM-Signature:MIME-Version:Date:Message-ID:Subject:To:From:From; bh=ACVLJDtrZTfvuqbghURDtPAAMBb43AYdpu6pKRCb3M8=; b=oUEwqPDcfpS1GfedpUZS9ECSqgNQDs1kioju+px8OY8SpXC9BO0UYY5nGRs+6dig832G 8j5EzdpdPQk9WTftRxhqDbVRBvUC6JDfW9D4nPhX3BNcgCODVhZ1Tm6vKVYKk2FywLrg4 wPdBeu0ehyIk9RdRyARGzNN06aIUPf30pRddRcoL/nIJWCjXGqeqH5y3BzxoLBF3mWdr7 MuY5V2ztL3A24g3/7RJ1vRf7WMZhnMk+AEPVI5AQ+sNzx0qtGxPCoiS0y1m47XapNRq25 c6RjgI9bcAyOuxo2djwmhhdy+fk6cHKBMJpd0LQ8qNosfSSuMrUifRsM3F1R9H5pTFw== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGSrj0tYGz17HD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1756823573; bh=ACVLJDtrZTfvuqbghURDtPAAMBb43AYdpu6pKRCb3M8=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=gcEOzFkEqBydB7bFUD3jBxvvln3LbtEvtNJIBT4fn2FfGyw/RcgvlpCTuU1Be2wUl 0v8Gj13d1tlueZBEN4YFF+AL3pj3Ua2balRX3s1RdZD5KlCdnIkJ2zHwtSCxmDQ/jk EyISqXmFTZ2hvyGDpxnyyI5RcvkKvzqsJ8XH79oL+UPcyJnNXfu6hZcnNSDsNIepGu tp3noN1h1AnxaLzYClq4Acc7W6JFbAl56yXWKQawtvLNlWAS16pdpgerDUESiobHEZ Be+rCAiCgInElWc13BtUZiZCsOYhAeo4H5n52d+LspqPWKnrlmPmoFpCT5cq+kFtV3 KzrIRaLQtZZLg== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cGSrj0tYGz17HD; Tue, 2 Sep 2025 10:32:53 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGSg15PD1z17T5 DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGSg15PD1z17T5 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lists.lttng.org (Postfix) with ESMTPS id 4cGSg15PD1z17T5 for ; Tue, 2 Sep 2025 10:24:29 -0400 (EDT) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-afcb78ead12so890272566b.1 for ; Tue, 02 Sep 2025 07:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756823068; x=1757427868; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Z+/p0Gh1FudMOfCHkMQrtIrA7irK0Sgn0L4RsHJMJ1o=; b=LcrWSxi4RZ/W9LRdZuJ2EZZO4A2pb1g8kRcCiEuqPolpx/Cqy0uBuIOnkvTB4p9n+Q MWPB7tw+uBDJUzdoOLeARUylRCcezqVjTDNAkMBOMMicWaQnirD1JQB2NkwQ1urYGEh3 g1OepoQU/YXdO8Oku2bf+QBALTBR6Ra4wE/CV3aECfa2yUhSU3jc450e8GVoEgSMSan6 BzhYMHgrkeUml2WNhk/tkSTHVCj0P9yTIhYaOnMbvhca8IyQiUjwTygDJNYRJ7D2RzjE rbbhW+XyKrQ06suUPRd2sAXmgIb3DWCi8HUZw9CnZltcwJQr1VR5pKNgd8fI6wecl6a+ 1qkw== X-Forwarded-Encrypted: i=1; AJvYcCWB0SUrq4A8AY+g6oYVDj5p2OnonKDnOs8+Pr2PPVdV8QzNZOkYx5fyUEZCk5zFShgL2EcKg1bKHSo=@lists.lttng.org X-Gm-Message-State: AOJu0Yzd7VEdNi41MIDARTWCAxHgLWtlnHX7qZ60v4Mgz2kHRw1FdkNI UvaIrrfaVWoX0ZUrMNBv700zGUtiIXOsnyoovK65ZFVd6Zp1Nf4CHLC8moNgUOP187hctOqhWJy tScp14j/OY0Vclf1feLPj63zoeaaxp4E= X-Gm-Gg: ASbGncu4KDw3HQvJ+9wwVCetpU0U/PPYvI8pHcTqepp5T7IAe/etAa25vCYkHNGi/9x 9xQAU0BVPMHfPOnk4SK//S8QGlCQ2h3bRbMBGO91t5fjfSvqqq9uLXLZlGxK1pTLhdp8VbxgaXP Ggn1VrtVJ8xR7JWV4YxKiG2BPbSPsoWqW4zo1kEAhYNO+sTq9qMHUzkPoUF7kPWroo7iFQV0jjn pyopi9MDJlmP5pU4xQ= X-Google-Smtp-Source: AGHT+IG6bbyyonJaxMV1V0fP2u1cRrsCzj6Po7dGO70wMkFuZcVFbc6zP0m/Af7dqcN/Kqx+8y7+U504Zf4KaLI8d/s= X-Received: by 2002:a17:907:7b94:b0:afe:7b8c:a583 with SMTP id a640c23a62f3a-b01d8a2fc2emr1109859066b.13.1756823067985; Tue, 02 Sep 2025 07:24:27 -0700 (PDT) MIME-Version: 1.0 References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> In-Reply-To: Date: Tue, 2 Sep 2025 16:24:16 +0200 X-Gm-Features: Ac12FXzJv3_E2GGb3GxoTH12yRnjRkEn3dRO0BzNiRy9UAbSz29537f9PkRP284 Message-ID: Subject: Re: URCU feature request? To: Mathieu Desnoyers Content-Type: multipart/alternative; boundary="000000000000e68e4f063dd23eda" X-Mailman-Approved-At: Tue, 02 Sep 2025 10:32:38 -0400 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: Thobias Knudsen via lttng-dev Reply-To: Thobias Knudsen Cc: Olivier Dion , lttng-dev@lists.lttng.org, paulmck Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" --000000000000e68e4f063dd23eda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =3D 4;. 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 i= t >> > 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 mak= e >> > 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=C3=B8n. 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 urc= u >> > 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 stil= l >> > 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 >> > --000000000000e68e4f063dd23eda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Figured out what rcu_read_ongoing does. It just returns tr= ue if it's called within=C2=A0a read section and false otherwise. The p= roblem for catching whether reads are done outside read sections is that yo= u can not make macros for read and write operations. e.g. ptr->a =3D 4;.=

tir. 2. sep. 2025 kl. 16:17 skrev Thobias Knudsen <= ;thobknu@gmail.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
> I su= spect that what you are trying to achieve is validation that
> calls = to functions that require to be within a RCU read-side critical
> sec= tion such as cds_lfht_lookup are indeed invoked from within a
> criti= cal section.

Yes exactly, but not only for read sections= . It could also be to validate that rcu_barrier isnt=C2=A0called within a c= allback function or that rcu_quiescent_state isnt called when thread is off= line

> We've added a "rcu_read_ongoing()" AP= I for that purpose to liburcu
> RCU flavors, but AFAIK it's not u= sed for any kind of validation
> within cds_lfht. This could indeed b= ecome a feature request that
> would apply to all liburcu data struct= ure 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 rep= o though.



man. 1. sep. 2025 kl. 17= :09 skrev Mathieu Desnoyers <mathieu.desnoyers@efficios.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 2025-08-31 16:48, Thobi= as Knudsen wrote:
> BTW i've made a macro library which overrides the
> urcu=C2=A0and=C2=A0lfht=C2=A0functions. It checks that you call the fu= nctions in the
> correct order. This has been really useful for debugging and I think i= t
> would be useful to have it integrated into urcu to make the it more us= er
> friendly. you could have it integrated=C2=A0with the macro DEBUG_RCU o= r make
> a new one, maybe DEBUG_FUNCTION_CALL_ORDER. The only thing it doesn= 9;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 li= burcu
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=C3=B8n. 31. aug. 2025 kl. 22:42 skrev Thobias Knudsen <thobknu@gmail.com
> <mailto:thob= knu@gmail.com>>:
>
>=C2=A0 =C2=A0 =C2=A0First question: why isn't Userspace RCU more po= pular?
>=C2=A0 =C2=A0 =C2=A0Second question: Why isn't it possible to creat= e issues in the urcu
>=C2=A0 =C2=A0 =C2=A0repo? Im asking for a feature here:
>=C2=A0 =C2=A0 =C2=A0Is it possible to make a function which checks if t= here are more
>=C2=A0 =C2=A0 =C2=A0callbacks queued by call_rcu? I need that because t= here are some
>=C2=A0 =C2=A0 =C2=A0callbacks which call call_rcu, and then calling rcu= _barrier once
>=C2=A0 =C2=A0 =C2=A0isn't=C2=A0enough and I therefore need a way to= check if there are still
>=C2=A0 =C2=A0 =C2=A0callbacks to wait on before terminating the program= . No worries if
>=C2=A0 =C2=A0 =C2=A0this is too much to ask for or if it isn't=C2= =A0possible. This
>=C2=A0 =C2=A0 =C2=A0functionality is only needed in termination because= otherwise
>=C2=A0 =C2=A0 =C2=A0isn't=C2=A0needed to call rcu_barrier multiple = times (at least so far)
>
>=C2=A0 =C2=A0 =C2=A0Best regards
>=C2=A0 =C2=A0 =C2=A0Thobias
>
>


--
Mathieu Desnoyers
EfficiOS Inc.
h= ttps://www.efficios.com
--000000000000e68e4f063dd23eda--