URCU feature request?

[Paul E. McKenney]

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