<div dir="ltr">> We usually rely on the debugging code in rcu_dereference() to check this<br>> sort of thing.  Or are you worried about the user leaking RCU-protected<br>> pointers out past the rcu_read_unlock()?<div><br></div><div>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.</div><div><br></div><div>Thanks</div><div>Thobias</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">tir. 2. sep. 2025 kl. 22:33 skrev Paul E. McKenney <<a href="mailto:paulmck@kernel.org">paulmck@kernel.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Sep 02, 2025 at 04:24:16PM +0200, Thobias Knudsen wrote:<br>
> Figured out what rcu_read_ongoing does. It just returns true if it's called<br>
> within a read section and false otherwise. The problem for catching whether<br>
> reads are done outside read sections is that you can not make macros for<br>
> read and write operations. e.g. ptr->a = 4;.<br>
<br>
We usually rely on the debugging code in rcu_dereference() to check this<br>
sort of thing.  Or are you worried about the user leaking RCU-protected<br>
pointers out past the rcu_read_unlock()?<br>
<br>
                                                        Thanx, Paul<br>
<br>
> tir. 2. sep. 2025 kl. 16:17 skrev Thobias Knudsen <<a href="mailto:thobknu@gmail.com" target="_blank">thobknu@gmail.com</a>>:<br>
> <br>
> > > I suspect that what you are trying to achieve is validation that<br>
> > > calls to functions that require to be within a RCU read-side critical<br>
> > > section such as cds_lfht_lookup are indeed invoked from within a<br>
> > > critical section.<br>
> ><br>
> > Yes exactly, but not only for read sections. It could also be to validate<br>
> > that rcu_barrier isnt called within a callback function or that<br>
> > rcu_quiescent_state isnt called when thread is offline<br>
> ><br>
> > > We've added a "rcu_read_ongoing()" API for that purpose to liburcu<br>
> > > RCU flavors, but AFAIK it's not used for any kind of validation<br>
> > > within cds_lfht. This could indeed become a feature request that<br>
> > > would apply to all liburcu data structure APIs.<br>
> ><br>
> > I can't find any documentation on rcu_read_ongoing. Btw the documentation<br>
> > for urcu in general is scattered all around the repo it seems. It should<br>
> > have been all at one place imo. Should I make a feature request for it? I<br>
> > don't know how stuff works inside this repo though.<br>
> ><br>
> ><br>
> ><br>
> > man. 1. sep. 2025 kl. 17:09 skrev Mathieu Desnoyers <<br>
> > <a href="mailto:mathieu.desnoyers@efficios.com" target="_blank">mathieu.desnoyers@efficios.com</a>>:<br>
> ><br>
> >> On 2025-08-31 16:48, Thobias Knudsen wrote:<br>
> >> > BTW i've made a macro library which overrides the<br>
> >> > urcu and lfht functions. It checks that you call the functions in the<br>
> >> > correct order. This has been really useful for debugging and I think it<br>
> >> > would be useful to have it integrated into urcu to make the it more<br>
> >> user<br>
> >> > friendly. you could have it integrated with the macro DEBUG_RCU or make<br>
> >> > a new one, maybe DEBUG_FUNCTION_CALL_ORDER. The only thing it doesn't<br>
> >> > catch is if you continue to use data from cds_lfht_lookup() after<br>
> >> > rcu_read_unlock()<br>
> >><br>
> >> I suspect that what you are trying to achieve is validation that<br>
> >> calls to functions that require to be within a RCU read-side critical<br>
> >> section such as cds_lfht_lookup are indeed invoked from within a<br>
> >> critical section.<br>
> >><br>
> >> We've added a "rcu_read_ongoing()" API for that purpose to liburcu<br>
> >> RCU flavors, but AFAIK it's not used for any kind of validation<br>
> >> within cds_lfht. This could indeed become a feature request that<br>
> >> would apply to all liburcu data structure APIs.<br>
> >><br>
> >> Thanks,<br>
> >><br>
> >> Mathieu<br>
> >><br>
> >> ><br>
> >> > søn. 31. aug. 2025 kl. 22:42 skrev Thobias Knudsen <<a href="mailto:thobknu@gmail.com" target="_blank">thobknu@gmail.com</a><br>
> >> > <mailto:<a href="mailto:thobknu@gmail.com" target="_blank">thobknu@gmail.com</a>>>:<br>
> >> ><br>
> >> >     First question: why isn't Userspace RCU more popular?<br>
> >> >     Second question: Why isn't it possible to create issues in the urcu<br>
> >> >     repo? Im asking for a feature here:<br>
> >> >     Is it possible to make a function which checks if there are more<br>
> >> >     callbacks queued by call_rcu? I need that because there are some<br>
> >> >     callbacks which call call_rcu, and then calling rcu_barrier once<br>
> >> >     isn't enough and I therefore need a way to check if there are still<br>
> >> >     callbacks to wait on before terminating the program. No worries if<br>
> >> >     this is too much to ask for or if it isn't possible. This<br>
> >> >     functionality is only needed in termination because otherwise<br>
> >> >     isn't needed to call rcu_barrier multiple times (at least so far)<br>
> >> ><br>
> >> >     Best regards<br>
> >> >     Thobias<br>
> >> ><br>
> >> ><br>
> >><br>
> >><br>
> >> --<br>
> >> Mathieu Desnoyers<br>
> >> EfficiOS Inc.<br>
> >> <a href="https://www.efficios.com" rel="noreferrer" target="_blank">https://www.efficios.com</a><br>
> >><br>
> ><br>
</blockquote></div>