From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id J2i3COqXt2hkuBIAWB0awg (envelope-from ) for ; Tue, 02 Sep 2025 21:20:42 -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=kLPXM2dv; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 148301E057; Tue, 02 Sep 2025 21:20:42 -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 286EE1E057 for ; Tue, 02 Sep 2025 21:20:41 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGlD84xSlz1V9K ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1756862441; b=V9Z2X6QOp9LhENNnmD1OWnJP5WPHkiQ1OVWTkvVMY0oPy/KQzWxFePxDEd3lCAO3OHgj jliiVatyhEl1Qcx0oZVAfhDvfrjpM830pPpFDO0lkSLfMuPSC70w3x3FZcXtctucdUlJL 2TQbTXBdnI2lrgTT68YsN8ycJ19acWyHIYiVL95oP99IzE++HzuFl7ovdGR9tX32ZMyTv acYsOuaO7I6V/hU8QQ9sApBoNqI4D+YQjZTd/vDjIJ8zbZs9rm0nAMLwaSh71awHhNshc gbYRwhVkBvjCbISXYuKJiXgAJygRxJ6YIe/4/Nlba8j8Qk5L5PDdvqncr//e+/u19SQ== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1756862441; h=DKIM-Signature:Date:To:Subject:Message-ID:MIME-Version:From:From; bh=S/mCCuvfCj6vsroyEgNr+qPb7jOaGZhrCyH0ECzK0zQ=; b=Yco3jJU6INsRuVQpTtbjJGNdOt7N9520MhkGQ3IXYgeiH3X6D/vmLmH44276/TxINbNw xjG/MXNjBU+AfoNsKLh3GAuy2JBdekO7UarFrMCXxUFNbBrAfNkVPwLSrMnjK+jacWzwS jysD7QOceh4dmhtLwq+kADBPEGwrdPCwhbdvJW8G343p3EKSpx3ExiU3iGfOvMBQjoZMk NA82UvQHZ0p2aAO2uE2UpDwxk/EekiM9aocPk7gE/TeSiKCFVDzUFRMUFvhbnfduHFDQf 2tQRZPM3iwrBU7ZVijYqUNeIZtLpZvr1hpzjtXGFbgkJVRI7GZFTApAu4ulWOby+Sow== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGlD84xSlz1V9K DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1756862441; bh=S/mCCuvfCj6vsroyEgNr+qPb7jOaGZhrCyH0ECzK0zQ=; 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=kLPXM2dvSzYXgNgFvLtDdQCU4frBgTCzb1NmWOxxgHYbxKlRtxuq7VTc9TpM3IwAa 0XO92X9vUmdXbq2/gVjkaAKMddaffwIU68yE74GDafMGJC5NGq+rvdgbx+ITxEbIyQ gyBi9eeYPljGNkk9BoFden2KPJxTwX4O5ZWWq/Gn5+Q9jBzkyFjcppf5INjRIN9BUG US4W1z6V0rucI/8tAfm3KyXWcOwYkD9aZVXVGrGGMQ4GWwduf8P1KyBEE59BP8yjjD rPReTelst0lKGgvdnnz5b/skVpzlB+hFkSZuHiDAwBERaX7CMqAbUzX9MOH3+ymtx/ jf4tIghxFuCuQ== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4cGlD84xSlz1V9K; Tue, 2 Sep 2025 21:20:40 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4cGlD66TQ5z1TkG DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4cGlD66TQ5z1TkG 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 4cGlD66TQ5z1TkG for ; Tue, 2 Sep 2025 21:20:38 -0400 (EDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id A565760223; Wed, 3 Sep 2025 01:20:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E0C6C4CEED; Wed, 3 Sep 2025 01:20:32 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 13DAECE0C15; Tue, 2 Sep 2025 18:20:32 -0700 (PDT) Date: Tue, 2 Sep 2025 18:20:32 -0700 To: Thobias Knudsen Subject: Re: URCU feature request? Message-ID: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> 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 11:06:08PM +0200, Thobias Knudsen wrote: > > 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()? > > Yes, that is what I'm worried about. For my case when using URCU that is my > biggest concern, as the debug macro "library" I made checks everything > else, if I haven't overlooked anything. One thing you could do is to make something like an rcu_assign_data() that does the assignment and checks rcu_read_ongoing(). Alternatively, if you are willing to put infrequent random delays in rcu_read_unlock(), an address sanitizer might detect the resulting use-after-free. Thanx, Paul > Thanks > Thobias > > tir. 2. sep. 2025 kl. 22:33 skrev Paul E. McKenney : > > > 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 < > > thobknu@gmail.com > > > >> > >: > > > >> > > > > >> > 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 > > > >> > > > > > >