From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0XYSLhUAt2hfPRIAWB0awg (envelope-from ) for ; Tue, 02 Sep 2025 10:32:53 -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=M8m4yT+w; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B7E311E04C; Tue, 02 Sep 2025 10:32:53 -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 1DCAA1E043 for ; Tue, 02 Sep 2025 10:32:53 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGSrj0KWjz17Tt ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1756823573; b=eHNFbgNml9h5taM0ELfW0ag4i7hnl7m3fix+gmJ4x5xF8s4BjG+oS+BnUgl5DNbtsrwe zHjZtgHrMSBwdWtM/gRXSdwn7SBw6/jVZJvi3rWf6KkynJMInqduagf+pi4vLVvAV+ycf KT8bm++qgMvILOiBBvfpbV+pOx1MbBJIpYsjLJz6V/XuBVd+1fUt4QWpeQxQQpkQeOosD 14uK0SSDkw5HUomVi1lba0al/fevEdu5iUWiZFtpx7AwtdGt5ux10eFNc0vnGe3WPKgzc ujRn1ah+Uovh0P0L26lI/Hqfwg3fbRIfPVQDh0F4AUUVsxyTr3plkcUa5TERGenhpvA== 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=D46T1oUPM4w2rkjI8Uj7lf1le/jUnQbhqPzkp/EXL8I=; b=Rvw57vMGpUHK7ivTjUGYhP/o4DQ8XpxzBmzPG/pqXZ/aBEdaRhZPWZjwY7TTRMiOHEdx 0L9GK9G7LBarGpkgO39WlAhWFviT/+59YnJvYjGaBNoXm2uoFlfCvWl1f8VZtgg5Go9l5 rxRn7iJrXktUFNVspZdfRmV2Br9qjiIeypx6p5MKsySxn5OxVNTIFW4QwjwcNPodW/4H7 mIYQM+LO3cHmyfqkeRMo4wCRwplbsv+vk+RrlOdWFoQfkHT8J+ecir2NBHwY4+WyZ8jTg c9T2fOMptThCXvCbhm/LxrtXkMmMBbF0C6UX3wet18Cluokp3kzxnTVdKBJ5m80sBUA== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGSrj0KWjz17Tt DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1756823573; bh=D46T1oUPM4w2rkjI8Uj7lf1le/jUnQbhqPzkp/EXL8I=; 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=M8m4yT+w1zUQRgeFk03vOTN7OYh8PVPCjfnpoAVzg7DXiMnuW32fx4oLXNoIbLrxa cf/ambV+ozFlUrOsqGjBv2+J81yN2LnQ5ovzbQ5C9fOW/ojlQ4VOtxhFYPwWDL4UKh WtNq885YzKbC/Jw68iHV2r+NwyWLiDIJgqo8BLfqtXK+D6wQF57XjdPXxWSsvo0CGm jv/q8wQAXLJ/cq3pJSspzYmxGTSdnPxWcskumKYkNl/i587MrdjRThFs0g8wI/qh6w VfBVzkXecadYlM2+LX5E/NAnbICCEegxciyBBeoqsmCmvOyEWn8xljm7jQnNse3DZi qPaudmUenVBLA== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cGSrj0KWjz17Tt; Tue, 2 Sep 2025 10:32:53 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGSW12HDXz17Sj DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGSW12HDXz17Sj Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lists.lttng.org (Postfix) with ESMTPS id 4cGSW12HDXz17Sj for ; Tue, 2 Sep 2025 10:17:32 -0400 (EDT) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-61cf0901a72so8019116a12.1 for ; Tue, 02 Sep 2025 07:17:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756822652; x=1757427452; 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=iqk4a8Lsh8kixJ7LldxH+VGsLG+RvRy/15d/FhsMCnU=; b=vzGYLv8o8knf0aUEgDcJZD33PXvVk+IwLD3aoGuBUC8JBcRsId1vKqrjD4TY6CMVgq dNHL8uYQqAOyBW8HHp7IQEWUSO2pymqRTsgKePoTmwTpmHdAxHEmTo/eQa6emf+AkDx9 q7ZxL8TyJ6HDVgGcU7RCJA5Ka2pij+dqQun2RXWYqYft6VrYy9dXOdCvRkwT9VnSOPol SGvMmB5ZoW3LSmwy2hU7f6ww1BHra0YV2ms31kKcJt0mKwbjV9fmvEEgEFRBJ81ZqgCh BPkJCeAMDzAzPBzRH+2Zh+dOefUXuf9JDZ1aQlPxbCaRagz7awWzpj3RjfDDDBUkZLvZ ycmw== X-Forwarded-Encrypted: i=1; AJvYcCX1R7ghnCyKosLJOfvG7Co4apE8Snu2h9glQVpp1nTCyDRDeJ1YJsXxCFsBXwM3jQT7n4OPdvpWsfY=@lists.lttng.org X-Gm-Message-State: AOJu0Yw6miqKHkxcm+Dp6dOmwXx+KsA/GV4ZSf9iTGCNxJ1gLjOZiwPL ZN3fwcZYJw+ouZRqM/6ZVQvkWrZ0EUWlrF20n2glq487odlP7ZmVmX+THgmsVnzlkujcmxNuiKf Rmo6DIaRdizFLMuybY8UzBAjETxQOQA8d2FTP+qo= X-Gm-Gg: ASbGncsKhugeGYRrOOYLqcmgR9jT6GouIv43ahCeUTUSWIqwqOfy4wYZtwAD+Ik9WmG IlWgP1FpiOkgpEHQ7T3jdEw24tD751Wd3QePm7PfwNCwEjOokPED8QzFIqnI4tVVcyO0kjLDTqM Q6ZtGcP//qK+BY77mV7wnJcRidj4zsM5cQBhFRI1LtdCwCpo4BmVWRiMjIM0a94Ua1xKpp48ADD 745COMKN3/m81k6iOU= X-Google-Smtp-Source: AGHT+IEpIlga3E0cQvy2O6wk9T+M6DePzG8GOdmCEpWJSJ37chI4p+UzPIOqg1/I7+utveVs4AWnRcYLdRKgSHB5hMA= X-Received: by 2002:a05:6402:270e:b0:61c:29e:db04 with SMTP id 4fb4d7f45d1cf-61d2686a7fcmr11773234a12.6.1756822651520; Tue, 02 Sep 2025 07:17:31 -0700 (PDT) MIME-Version: 1.0 References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> In-Reply-To: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> Date: Tue, 2 Sep 2025 16:17:19 +0200 X-Gm-Features: Ac12FXy0Zkw6AaYScFe6RH20uXAbQVAtFZuNwycLg13MFnHgzTfxf2Q7iULvnIg Message-ID: Subject: Re: URCU feature request? To: Mathieu Desnoyers Content-Type: multipart/alternative; boundary="00000000000013c93f063dd226a3" 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" --00000000000013c93f063dd226a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 use= r > > 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=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 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 > --00000000000013c93f063dd226a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I suspect that what you are trying to achieve is vali= dation that
> calls to functions that require to be within a RCU read= -side critical
> section such as cds_lfht_lookup are indeed invoked f= rom within a
> critical section.

Yes exactly, but = not only for read sections. It could also be to validate that rcu_barrier i= snt=C2=A0called within a callback function or that rcu_quiescent_state isnt= called when thread is offline

> We've added a "r= cu_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 gener= al is scattered all around the repo it seems. It should have been all at on= e place imo. Should I make a feature request for it? I don't know how s= tuff works inside this repo though.



man. 1. sep. 2025 kl. 17:09 skrev Mathieu Desnoyers= <mathieu.desnoyers@ef= ficios.com>:
On 2025-08-31 16:48, Thobias 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
--00000000000013c93f063dd226a3--