URCU feature request?

[Thobias Knudsen]

> 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 at 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 at efficios.com>:
>
>> On Tue, 02 Sep 2025, Thobias Knudsen via lttng-dev <
>> lttng-dev at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20250904/9f6009f8/attachment.htm>