Re: URCU feature request?

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

> github repo is only a mirror. From the README.md you will notice a
> link to:
>
> Bug tracker: [Userspace RCU bug tracker](
https://bugs.lttng.org/projects/urcu)
>
> which has a "Feature" category.

Yes I actually visited that page. I just forgot to mention it. But I
couldn't create a feature request. I guess I have to create an account
then? I tried to create an account now and I have to wait for it to be
verified. Why isn't the issues just on github instead as people are more
familiar with that?

> The flag approach would allow your application to eventually complete,
> which may not be the case if you endlessly wait for all callbacks to
> be completed without preventing further callbacks to be enqueued.

In my case I have made a wrapper over cds_lfht which allows for recursive
lfht inside each other. for all lfht nodes there is a callback function
which in turn calls call_rcu on all the children lfht nodes. That means the
number of rcu_barriers needed to be called at program exit is the same as
the depth of lfht nodes. In this case there will never be an infinite
callback chain so if I understood correctly then I don't think using a flag
is relevant. I could iterate over every node to check the max depth but
that seems dirty. Isn't there an internal variable to check for how many
callbacks are left or if there are any at all? Or maybe it's unsafe to
access it?

man. 1. sep. 2025 kl. 17:04 skrev Mathieu Desnoyers <
mathieu.desnoyers@efficios.com>:

> On 2025-08-31 16:42, Thobias Knudsen wrote:
> > First question: why isn't Userspace RCU more popular?
>
> One guess is that for many use-cases, locking is sufficient.
>
> RCU and lock-free data structures are relevant in performance, latency,
> and scalability sensitive use-cases.
>
> And of course we could probably do a better job at advertising its
> existence.
>
> > Second question: Why isn't it possible to create issues in the urcu
> > repo?
>
> github repo is only a mirror. From the README.md you will notice a
> link to:
>
> Bug tracker: [Userspace RCU bug tracker](
> https://bugs.lttng.org/projects/urcu)
>
> which has a "Feature" category.
>
> > 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)
>
> Here is a relevant comment at the top of urcu_call_rcu_exit:
>
>   * Here is how an application can ensure graceful teardown of this
>   * worker thread:
>   *
>   * - An application queuing call_rcu callbacks should invoke
>   *   rcu_barrier() before it exits.
>   * - When chaining call_rcu callbacks, the number of calls to
>   *   rcu_barrier() on application exit must match at least the maximum
>   *   number of chained callbacks.
>   * - If an application chains callbacks endlessly, it would have to be
>   *   modified to stop chaining callbacks when it detects an application
>   *   exit (e.g. with a flag), and wait for quiescence with rcu_barrier()
>   *   after setting that flag.
>   * - The statements above apply to a library which queues call_rcu
>   *   callbacks, only it needs to invoke rcu_barrier in its library
>   *   destructor.
>
> The flag approach would allow your application to eventually complete,
> which may not be the case if you endlessly wait for all callbacks to
> be completed without preventing further callbacks to be enqueued.
>
> Ideally please include the lttng-dev mailing list on those discussions
> in the future, so everyone can benefit from them.
>
> Thanks,
>
> Mathieu
>
> >
> > Best regards
> > Thobias
> >
> >
>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com
>

[-- Attachment #2: Type: text/html, Size: 5135 bytes --]

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

> 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
> > <mailto: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
>

[-- Attachment #2: Type: text/html, Size: 4124 bytes --]

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 3640 bytes --]

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;.

tir. 2. sep. 2025 kl. 16:17 skrev Thobias Knudsen <thobknu@gmail.com>:

> > 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
>> > <mailto: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
>>
>

[-- Attachment #2: Type: text/html, Size: 4768 bytes --]

Re: URCU feature request?

[Paul E. McKenney via 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 <thobknu@gmail.com>:
> 
> > > 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
> >> > <mailto: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
> >>
> >

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 4845 bytes --]

> 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.

Thanks
Thobias

tir. 2. sep. 2025 kl. 22:33 skrev Paul E. McKenney <paulmck@kernel.org>:

> 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 <thobknu@gmail.com>:
> >
> > > > 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
> > >> > <mailto: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
> > >>
> > >
>

[-- Attachment #2: Type: text/html, Size: 6581 bytes --]

Re: URCU feature request?

[Ondřej Surý via lttng-dev]

If I understand you correctly, you can do something like this:

#undef rcu_read_lock
#define rcu_read_lock() urcu_memb_read_lock(); {

#undef rcu_read_unlock
#define rcu_read_lock() } urcu_memb_read_unlock();

(replace memb with your RCU variant of course)

and make your code declare all the RCU protected pointers inside the RCU critical section, e.g.

rcu_read_lock();
my_pointer *foo = rcu_dereference(...);

use(foo); /* valid */

rcu_read_unlock();


use(foo); /* invalid and caught by the compiler */

Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

> On 2. 9. 2025, at 23:06, Thobias Knudsen via lttng-dev <lttng-dev@lists.lttng.org> wrote:
> 
> 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.
> 

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

Yes but all read/write operations doesn't have the syntax of a function as
you used in the example here i.e. use(...). When it is a function you can
easily just change the implementation to check if it is called inside a
read section. Some reads and writes are usually done by this syntax (a = b)
and '=' cannot be overridden.

BTW just saying that what we're talking about now is not the original
topic, but if someone has an elegant solution to this that would be nice!

Thanks
Thobias

tir. 2. sep. 2025 kl. 23:34 skrev Ondřej Surý <ondrej@sury.org>:

> If I understand you correctly, you can do something like this:
>
> #undef rcu_read_lock
> #define rcu_read_lock() urcu_memb_read_lock(); {
>
> #undef rcu_read_unlock
> #define rcu_read_lock() } urcu_memb_read_unlock();
>
> (replace memb with your RCU variant of course)
>
> and make your code declare all the RCU protected pointers inside the RCU
> critical section, e.g.
>
> rcu_read_lock();
> my_pointer *foo = rcu_dereference(...);
>
> use(foo); /* valid */
>
> rcu_read_unlock();
>
>
> use(foo); /* invalid and caught by the compiler */
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ondrej@sury.org
>
> > On 2. 9. 2025, at 23:06, Thobias Knudsen via lttng-dev <
> lttng-dev@lists.lttng.org> wrote:
> >
> > 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.
> >
>
>

[-- Attachment #2: Type: text/html, Size: 2092 bytes --]

Re: URCU feature request?

[Paul E. McKenney via 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 <paulmck@kernel.org>:
> 
> > 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 <thobknu@gmail.com>:
> > >
> > > > > 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
> > > >> > <mailto: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
> > > >>
> > > >
> >

Re: URCU feature request?

[Olivier Dion via lttng-dev]

On Tue, 02 Sep 2025, Thobias Knudsen via lttng-dev <lttng-dev@lists.lttng.org> wrote:
> Yes but all read/write operations doesn't have the syntax of a function as
> you used in the example here i.e. use(...). When it is a function you can
> easily just change the implementation to check if it is called inside a
> read section. Some reads and writes are usually done by this syntax (a = b)
> and '=' cannot be overridden.
>
> BTW just saying that what we're talking about now is not the original
> topic, but if someone has an elegant solution to this that would be
> nice!

I am confuse about the overall discussion here.  Are we talking about
static checking of RCU pointers usage or runtime checking?

Is is possible to see the implementation you made so I can understand
better?

Thanks,
Olivier
-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

> I am confuse about the overall discussion here.  Are we talking about
> static checking of RCU pointers usage or runtime checking?
>
> Is is possible to see the implementation you made so I can understand
> better?

Sorry for being late to answer :/
The library overrides a subset of urcu and lfht functions with macros and
replaces them with other functions which checks in runtime if the functions
are called in the correct order.
here is the code: https://github.com/ThobiasKnudsen/urcu_lfht_safe


ons. 3. sep. 2025 kl. 03:35 skrev Olivier Dion <odion@efficios.com>:

> On Tue, 02 Sep 2025, Thobias Knudsen via lttng-dev <
> lttng-dev@lists.lttng.org> wrote:
> > Yes but all read/write operations doesn't have the syntax of a function
> as
> > you used in the example here i.e. use(...). When it is a function you can
> > easily just change the implementation to check if it is called inside a
> > read section. Some reads and writes are usually done by this syntax (a =
> b)
> > and '=' cannot be overridden.
> >
> > BTW just saying that what we're talking about now is not the original
> > topic, but if someone has an elegant solution to this that would be
> > nice!
>
> I am confuse about the overall discussion here.  Are we talking about
> static checking of RCU pointers usage or runtime checking?
>
> Is is possible to see the implementation you made so I can understand
> better?
>
> Thanks,
> Olivier
> --
> Olivier Dion
> EfficiOS Inc.
> https://www.efficios.com
>
>

[-- Attachment #2: Type: text/html, Size: 2195 bytes --]

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

> 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.

Sorry for being late to answer :/
I have thought of that but it's so easy to just not use rcu_assign_data()
or a equivalent read function to check if the read is done within a read
section. Maybe it's the best possible option

Thanks
Thobias

tor. 4. sep. 2025 kl. 20:06 skrev Thobias Knudsen <thobknu@gmail.com>:

> > I am confuse about the overall discussion here.  Are we talking about
> > static checking of RCU pointers usage or runtime checking?
> >
> > Is is possible to see the implementation you made so I can understand
> > better?
>
> Sorry for being late to answer :/
> The library overrides a subset of urcu and lfht functions with macros and
> replaces them with other functions which checks in runtime if the functions
> are called in the correct order.
> here is the code: https://github.com/ThobiasKnudsen/urcu_lfht_safe
>
>
> ons. 3. sep. 2025 kl. 03:35 skrev Olivier Dion <odion@efficios.com>:
>
>> On Tue, 02 Sep 2025, Thobias Knudsen via lttng-dev <
>> lttng-dev@lists.lttng.org> wrote:
>> > Yes but all read/write operations doesn't have the syntax of a function
>> as
>> > you used in the example here i.e. use(...). When it is a function you
>> can
>> > easily just change the implementation to check if it is called inside a
>> > read section. Some reads and writes are usually done by this syntax (a
>> = b)
>> > and '=' cannot be overridden.
>> >
>> > BTW just saying that what we're talking about now is not the original
>> > topic, but if someone has an elegant solution to this that would be
>> > nice!
>>
>> I am confuse about the overall discussion here.  Are we talking about
>> static checking of RCU pointers usage or runtime checking?
>>
>> Is is possible to see the implementation you made so I can understand
>> better?
>>
>> Thanks,
>> Olivier
>> --
>> Olivier Dion
>> EfficiOS Inc.
>> https://www.efficios.com
>>
>>

[-- Attachment #2: Type: text/html, Size: 3206 bytes --]

Re: URCU feature request?

[Olivier Dion via lttng-dev]

On Thu, 04 Sep 2025, Thobias Knudsen <thobknu@gmail.com> wrote:
>> I am confuse about the overall discussion here.  Are we talking about
>> static checking of RCU pointers usage or runtime checking?
>>
>> Is is possible to see the implementation you made so I can understand
>> better?
>
> Sorry for being late to answer :/
> The library overrides a subset of urcu and lfht functions with macros and
> replaces them with other functions which checks in runtime if the functions
> are called in the correct order.
> here is the code: https://github.com/ThobiasKnudsen/urcu_lfht_safe

It looks like you want runtime verification for the usage of the API.
Did you know that URCU can now be compiled against ThreadSanitizer
(TSAN)?  If a user misuses the API or makes incorrect assumptions about
the guarantees offered by RCU, TSAN will most likely detect those
issues.  Coupled with the other debug features we already have, this
makes it very hard to not trigger an error path when the API is used
incorrectly.

Note that certain kind of errors could actually be flag at compile time
with the proper tooling.  For example, the Linux kernel uses a `__rcu'
attribute that Sparse can understand to flag improper use of
RCU‑protected pointers.  I’d be very open to exposing something similar
(an attribute) for static checkers.

[...]

Thanks,
Olivier
-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 3003 bytes --]

> It looks like you want runtime verification for the usage of the API.
> Did you know that URCU can now be compiled against ThreadSanitizer
> (TSAN)?  If a user misuses the API or makes incorrect assumptions about
> the guarantees offered by RCU, TSAN will most likely detect those
> issues.  Coupled with the other debug features we already have, this
> makes it very hard to not trigger an error path when the API is used
> incorrectly.

Really?! I've used TSAN and got a bunch of false positives, I believe, but
maybe they're not false positives? How do you remove the false positives,
or know that they're not false positives?

> Note that certain kind of errors could actually be flag at compile time
> with the proper tooling.  For example, the Linux kernel uses a `__rcu'
> attribute that Sparse can understand to flag improper use of
> RCU‑protected pointers.  I’d be very open to exposing something similar
> (an attribute) for static checkers.

wow thanks for the info! I knew compile time checks would be possible but
requiring compiler operability which is a higher hanging fruit for me. Is
'__rcu' compatible with custom concurrency? For example rcu_dereference a
pointer then locking a mutex inside the pointer then unlock read then
continue using the pointer? I cant come up with something usefull other
than a language rework. Is it much work making the __urcu attribute?

fre. 5. sep. 2025 kl. 20:04 skrev Olivier Dion <odion@efficios.com>:

> On Thu, 04 Sep 2025, Thobias Knudsen <thobknu@gmail.com> wrote:
> >> I am confuse about the overall discussion here.  Are we talking about
> >> static checking of RCU pointers usage or runtime checking?
> >>
> >> Is is possible to see the implementation you made so I can understand
> >> better?
> >
> > Sorry for being late to answer :/
> > The library overrides a subset of urcu and lfht functions with macros and
> > replaces them with other functions which checks in runtime if the
> functions
> > are called in the correct order.
> > here is the code: https://github.com/ThobiasKnudsen/urcu_lfht_safe
>
> It looks like you want runtime verification for the usage of the API.
> Did you know that URCU can now be compiled against ThreadSanitizer
> (TSAN)?  If a user misuses the API or makes incorrect assumptions about
> the guarantees offered by RCU, TSAN will most likely detect those
> issues.  Coupled with the other debug features we already have, this
> makes it very hard to not trigger an error path when the API is used
> incorrectly.
>
> Note that certain kind of errors could actually be flag at compile time
> with the proper tooling.  For example, the Linux kernel uses a `__rcu'
> attribute that Sparse can understand to flag improper use of
> RCU‑protected pointers.  I’d be very open to exposing something similar
> (an attribute) for static checkers.
>
> [...]
>
> Thanks,
> Olivier
> --
> Olivier Dion
> EfficiOS Inc.
> https://www.efficios.com
>

[-- Attachment #2: Type: text/html, Size: 3893 bytes --]

Re: URCU feature request?

[Olivier Dion via lttng-dev]

On Sun, 07 Sep 2025, Thobias Knudsen <thobknu@gmail.com> wrote:
>> It looks like you want runtime verification for the usage of the API.
>> Did you know that URCU can now be compiled against ThreadSanitizer
>> (TSAN)?  If a user misuses the API or makes incorrect assumptions about
>> the guarantees offered by RCU, TSAN will most likely detect those
>> issues.  Coupled with the other debug features we already have, this
>> makes it very hard to not trigger an error path when the API is used
>> incorrectly.
>
> Really?! I've used TSAN and got a bunch of false positives, I believe, but
> maybe they're not false positives? How do you remove the false positives,
> or know that they're not false positives?

Since 0.15.0, we've introduce an annotation layer (not part of the
public API), making TSAN compatible with URCU.  See
`include/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro.

However, IIRC, you also need to compile URCU with the configuration
option `--enable-compiler-atomic-builtins' so that atomic operations are
implemented with the configured toolchain's builtin atomics.  I don't
recall if this was stricly necessary.

If you encounter false positives with TSAN, please send me a minimal
reproducible example together with:

 - the toolchain you’re using
 
 - the version of URCU
 
 - the configuration flags you used

I will be happy to have a look.

>> Note that certain kind of errors could actually be flag at compile time
>> with the proper tooling.  For example, the Linux kernel uses a `__rcu'
>> attribute that Sparse can understand to flag improper use of
>> RCU‑protected pointers.  I’d be very open to exposing something similar
>> (an attribute) for static checkers.
>
> wow thanks for the info! I knew compile time checks would be possible but
> requiring compiler operability which is a higher hanging fruit for me. 

I don’t know the details of `__rcu' from the Linux kernel. I think it’s
just a macro that expands to nothing by default, but Sparse treats it as
an attribute.  I’m not sure exactly what checks Sparse performs with it,
but I suspect it involves traversing the program’s control-flow graph
(CFG), ensuring that pointers marked with the `__rcu' qualifier are:

  - obtained via rcu_dereference
  
  - only dereferenced under RCU lock protection

> Is '__rcu' compatible with custom concurrency? For example
> rcu_dereference a pointer then locking a mutex inside the pointer then
> unlock read then continue using the pointer?

I don’t see why that would be a problem for the static-check algorithm I
described above.  If a pointer needs to be protected by a mutex for
mutation, that falls outside the scope of RCU, as far as I know.

> I cant come up with something usefull other than a language rework. Is
> it much work making the __urcu attribute?

I suppose not.  On top of my head, it would involve adding some pointer
qualifier and function attributes to the primitives exposed by URCU.
Users would also need to use the pointer qualifier when working with
RCU-protected pointers.  The qualifier and the attributes would expand
to nothing by default, letting static checkers defining them to internal
values.  I suggest you read `Documentation/RCU/rcu_dereference.rst' in
the Linux kernel tree if you are interested.

In its current state, this would not be very useful because none of the
major compilers provide static analysis for RCU.  However, implementing
such analysis, as a plugin, wouldn’t be overly difficult for someone
familiar with Clang or GCC, I suppose.

[...]

Thanks,
Olivier
-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 6862 bytes --]

>Since 0.15.0, we've introduce an annotation layer (not part of the
>public API), making TSAN compatible with URCU.  See
>`include/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro.
>
>However, IIRC, you also need to compile URCU with the configuration
>option `--enable-compiler-atomic-builtins' so that atomic operations are
>implemented with the configured toolchain's builtin atomics.  I don't
>recall if this was strictly necessary.
>
>If you encounter false positives with TSAN, please send me a minimal
>reproducible example together with:
>
> - the toolchain you’re using
>
> - the version of URCU
>
> - the configuration flags you used
>
>I will be happy to have a look.

Sorry for the late answer. I had to find the time to fix some bugs to get
it all running before switching to urcu v0.15.0 and setting the flags and
macros for thread sanitizer support. Creating a minimum reproducible
example would take some time as I don't have any good idea of the
exact place where the thread sanitizer issues arise because they are
scattered all over tsm.c and test_tsm.c. If you have linux debian family
then you can clone my repo and run it:
https://github.com/ThobiasKnudsen/Logos. ./scripts/build.sh --debug --tsan
&& ./build/bin/test_tsm. I tried running with and without thread sanitizer
support and got the same issues. In the test_tsm when only one thread is
running, the thread sanitizer produces warnings still. I did find a place
where the thread sanitizer said there was a race and the write was within a
node not yet inserted into the cds_lfht. That seems like a false positive.
The read for the same case should be inside rcu_read_lock as everything
within lines 263 to 904 inside test_tsm.c is within a read section.

  Read of size 1 at 0x7b1400085ea1 by thread T6:
    #0 tsm_base_node_is_valid /Logos/src/tsm.c:721 (test_tsm+0xa548)
    #1 _tsm_tsm_type_is_valid /Logos/src/tsm.c:364 (test_tsm+0xb1bf)
    #2 tsm_node_is_valid /Logos/src/tsm.c:1553 (test_tsm+0x9984)
    #3 tsm_node_defer_free /Logos/src/tsm.c:1888 (test_tsm+0xb2fc)
    #4 stress_thread /Logos/src/tests/test_tsm.c:549 (test_tsm+0x46a6)

  Previous write of size 1 at 0x7b1400085ea1 by thread T9:
    #0 tsm_base_node_create /Logos/src/tsm.c:683 (test_tsm+0x6f2a)
    #1 stress_thread /Logos/src/tests/test_tsm.c:843 (test_tsm+0x5ce0)

>I don’t see why that would be a problem for the static-check algorithm I
>described above.  If a pointer needs to be protected by a mutex for
>mutation, that falls outside the scope of RCU, as far as I know.

If I understand correctly the __rcu checks that reads are not done outside
read sections and unsafe writes are not done at all. If this is correct
then if you are using custom concurrency for __rcu protected data outside
the read section or unsafe writes is that allowed? Because if it's not that
would be a limitation for __rcu.

man. 8. sep. 2025 kl. 02:10 skrev Olivier Dion <odion@efficios.com>:

> On Sun, 07 Sep 2025, Thobias Knudsen <thobknu@gmail.com> wrote:
> >> It looks like you want runtime verification for the usage of the API.
> >> Did you know that URCU can now be compiled against ThreadSanitizer
> >> (TSAN)?  If a user misuses the API or makes incorrect assumptions about
> >> the guarantees offered by RCU, TSAN will most likely detect those
> >> issues.  Coupled with the other debug features we already have, this
> >> makes it very hard to not trigger an error path when the API is used
> >> incorrectly.
> >
> > Really?! I've used TSAN and got a bunch of false positives, I believe,
> but
> > maybe they're not false positives? How do you remove the false positives,
> > or know that they're not false positives?
>
> Since 0.15.0, we've introduce an annotation layer (not part of the
> public API), making TSAN compatible with URCU.  See
> `include/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro.
>
> However, IIRC, you also need to compile URCU with the configuration
> option `--enable-compiler-atomic-builtins' so that atomic operations are
> implemented with the configured toolchain's builtin atomics.  I don't
> recall if this was stricly necessary.
>
> If you encounter false positives with TSAN, please send me a minimal
> reproducible example together with:
>
>  - the toolchain you’re using
>
>  - the version of URCU
>
>  - the configuration flags you used
>
> I will be happy to have a look.
>
> >> Note that certain kind of errors could actually be flag at compile time
> >> with the proper tooling.  For example, the Linux kernel uses a `__rcu'
> >> attribute that Sparse can understand to flag improper use of
> >> RCU‑protected pointers.  I’d be very open to exposing something similar
> >> (an attribute) for static checkers.
> >
> > wow thanks for the info! I knew compile time checks would be possible but
> > requiring compiler operability which is a higher hanging fruit for me.
>
> I don’t know the details of `__rcu' from the Linux kernel. I think it’s
> just a macro that expands to nothing by default, but Sparse treats it as
> an attribute.  I’m not sure exactly what checks Sparse performs with it,
> but I suspect it involves traversing the program’s control-flow graph
> (CFG), ensuring that pointers marked with the `__rcu' qualifier are:
>
>   - obtained via rcu_dereference
>
>   - only dereferenced under RCU lock protection
>
> > Is '__rcu' compatible with custom concurrency? For example
> > rcu_dereference a pointer then locking a mutex inside the pointer then
> > unlock read then continue using the pointer?
>
> I don’t see why that would be a problem for the static-check algorithm I
> described above.  If a pointer needs to be protected by a mutex for
> mutation, that falls outside the scope of RCU, as far as I know.
>
> > I cant come up with something usefull other than a language rework. Is
> > it much work making the __urcu attribute?
>
> I suppose not.  On top of my head, it would involve adding some pointer
> qualifier and function attributes to the primitives exposed by URCU.
> Users would also need to use the pointer qualifier when working with
> RCU-protected pointers.  The qualifier and the attributes would expand
> to nothing by default, letting static checkers defining them to internal
> values.  I suggest you read `Documentation/RCU/rcu_dereference.rst' in
> the Linux kernel tree if you are interested.
>
> In its current state, this would not be very useful because none of the
> major compilers provide static analysis for RCU.  However, implementing
> such analysis, as a plugin, wouldn’t be overly difficult for someone
> familiar with Clang or GCC, I suppose.
>
> [...]
>
> Thanks,
> Olivier
> --
> Olivier Dion
> EfficiOS Inc.
> https://www.efficios.com
>

[-- Attachment #2: Type: text/html, Size: 7976 bytes --]

Re: URCU feature request?

[Thobias Knudsen via lttng-dev]

[-- Attachment #1: Type: text/plain, Size: 7187 bytes --]

I forgot to say

Thanks,
Thobias

fre. 19. sep. 2025 kl. 22:39 skrev Thobias Knudsen <thobknu@gmail.com>:

> >Since 0.15.0, we've introduce an annotation layer (not part of the
> >public API), making TSAN compatible with URCU.  See
> >`include/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro.
> >
> >However, IIRC, you also need to compile URCU with the configuration
> >option `--enable-compiler-atomic-builtins' so that atomic operations are
> >implemented with the configured toolchain's builtin atomics.  I don't
> >recall if this was strictly necessary.
> >
> >If you encounter false positives with TSAN, please send me a minimal
> >reproducible example together with:
> >
> > - the toolchain you’re using
> >
> > - the version of URCU
> >
> > - the configuration flags you used
> >
> >I will be happy to have a look.
>
> Sorry for the late answer. I had to find the time to fix some bugs to get
> it all running before switching to urcu v0.15.0 and setting the flags and
> macros for thread sanitizer support. Creating a minimum reproducible
> example would take some time as I don't have any good idea of the
> exact place where the thread sanitizer issues arise because they are
> scattered all over tsm.c and test_tsm.c. If you have linux debian family
> then you can clone my repo and run it:
> https://github.com/ThobiasKnudsen/Logos. ./scripts/build.sh --debug
> --tsan && ./build/bin/test_tsm. I tried running with and without thread
> sanitizer support and got the same issues. In the test_tsm when only one
> thread is running, the thread sanitizer produces warnings still. I did find
> a place where the thread sanitizer said there was a race and the write was
> within a node not yet inserted into the cds_lfht. That seems like a false
> positive. The read for the same case should be inside rcu_read_lock as
> everything within lines 263 to 904 inside test_tsm.c is within a read
> section.
>
>   Read of size 1 at 0x7b1400085ea1 by thread T6:
>     #0 tsm_base_node_is_valid /Logos/src/tsm.c:721 (test_tsm+0xa548)
>     #1 _tsm_tsm_type_is_valid /Logos/src/tsm.c:364 (test_tsm+0xb1bf)
>     #2 tsm_node_is_valid /Logos/src/tsm.c:1553 (test_tsm+0x9984)
>     #3 tsm_node_defer_free /Logos/src/tsm.c:1888 (test_tsm+0xb2fc)
>     #4 stress_thread /Logos/src/tests/test_tsm.c:549 (test_tsm+0x46a6)
>
>   Previous write of size 1 at 0x7b1400085ea1 by thread T9:
>     #0 tsm_base_node_create /Logos/src/tsm.c:683 (test_tsm+0x6f2a)
>     #1 stress_thread /Logos/src/tests/test_tsm.c:843 (test_tsm+0x5ce0)
>
> >I don’t see why that would be a problem for the static-check algorithm I
> >described above.  If a pointer needs to be protected by a mutex for
> >mutation, that falls outside the scope of RCU, as far as I know.
>
> If I understand correctly the __rcu checks that reads are not done outside
> read sections and unsafe writes are not done at all. If this is correct
> then if you are using custom concurrency for __rcu protected data outside
> the read section or unsafe writes is that allowed? Because if it's not that
> would be a limitation for __rcu.
>
> man. 8. sep. 2025 kl. 02:10 skrev Olivier Dion <odion@efficios.com>:
>
>> On Sun, 07 Sep 2025, Thobias Knudsen <thobknu@gmail.com> wrote:
>> >> It looks like you want runtime verification for the usage of the API.
>> >> Did you know that URCU can now be compiled against ThreadSanitizer
>> >> (TSAN)?  If a user misuses the API or makes incorrect assumptions about
>> >> the guarantees offered by RCU, TSAN will most likely detect those
>> >> issues.  Coupled with the other debug features we already have, this
>> >> makes it very hard to not trigger an error path when the API is used
>> >> incorrectly.
>> >
>> > Really?! I've used TSAN and got a bunch of false positives, I believe,
>> but
>> > maybe they're not false positives? How do you remove the false
>> positives,
>> > or know that they're not false positives?
>>
>> Since 0.15.0, we've introduce an annotation layer (not part of the
>> public API), making TSAN compatible with URCU.  See
>> `include/urcu/annotate.h' and the `CMM_SANITIZE_THREAD' macro.
>>
>> However, IIRC, you also need to compile URCU with the configuration
>> option `--enable-compiler-atomic-builtins' so that atomic operations are
>> implemented with the configured toolchain's builtin atomics.  I don't
>> recall if this was stricly necessary.
>>
>> If you encounter false positives with TSAN, please send me a minimal
>> reproducible example together with:
>>
>>  - the toolchain you’re using
>>
>>  - the version of URCU
>>
>>  - the configuration flags you used
>>
>> I will be happy to have a look.
>>
>> >> Note that certain kind of errors could actually be flag at compile time
>> >> with the proper tooling.  For example, the Linux kernel uses a `__rcu'
>> >> attribute that Sparse can understand to flag improper use of
>> >> RCU‑protected pointers.  I’d be very open to exposing something similar
>> >> (an attribute) for static checkers.
>> >
>> > wow thanks for the info! I knew compile time checks would be possible
>> but
>> > requiring compiler operability which is a higher hanging fruit for me.
>>
>> I don’t know the details of `__rcu' from the Linux kernel. I think it’s
>> just a macro that expands to nothing by default, but Sparse treats it as
>> an attribute.  I’m not sure exactly what checks Sparse performs with it,
>> but I suspect it involves traversing the program’s control-flow graph
>> (CFG), ensuring that pointers marked with the `__rcu' qualifier are:
>>
>>   - obtained via rcu_dereference
>>
>>   - only dereferenced under RCU lock protection
>>
>> > Is '__rcu' compatible with custom concurrency? For example
>> > rcu_dereference a pointer then locking a mutex inside the pointer then
>> > unlock read then continue using the pointer?
>>
>> I don’t see why that would be a problem for the static-check algorithm I
>> described above.  If a pointer needs to be protected by a mutex for
>> mutation, that falls outside the scope of RCU, as far as I know.
>>
>> > I cant come up with something usefull other than a language rework. Is
>> > it much work making the __urcu attribute?
>>
>> I suppose not.  On top of my head, it would involve adding some pointer
>> qualifier and function attributes to the primitives exposed by URCU.
>> Users would also need to use the pointer qualifier when working with
>> RCU-protected pointers.  The qualifier and the attributes would expand
>> to nothing by default, letting static checkers defining them to internal
>> values.  I suggest you read `Documentation/RCU/rcu_dereference.rst' in
>> the Linux kernel tree if you are interested.
>>
>> In its current state, this would not be very useful because none of the
>> major compilers provide static analysis for RCU.  However, implementing
>> such analysis, as a plugin, wouldn’t be overly difficult for someone
>> familiar with Clang or GCC, I suppose.
>>
>> [...]
>>
>> Thanks,
>> Olivier
>> --
>> Olivier Dion
>> EfficiOS Inc.
>> https://www.efficios.com
>>
>

[-- Attachment #2: Type: text/html, Size: 8426 bytes --]