Re: URCU feature request?
Thobias Knudsen via lttng-dev <[email protected]> Tue, 2 Sep 2025 23:06:08 +0200
| Newsgroups | org.lttng.lists.lttng-dev |
|---|---|
| Message-ID | <CAKGpciq+ixOVGN7TXYaF336ZEL_mOejzic5BvaKbexwwn_aqOQ@mail.gmail.com> |
--0000000000001577db063dd7dc69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 <[email protected]>: > 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 fo= r > > read and write operations. e.g. ptr->a =3D 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 <[email protected]>: > > > > > > I suspect that what you are trying to achieve is validation that > > > > calls to functions that require to be within a RCU read-side critic= al > > > > 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 < > > > [email protected]>: > > > > > >> 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 mor= e > > >> 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 critica= l > > >> 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=C3=B8n. 31. aug. 2025 kl. 22:42 skrev Thobias Knudsen < > [email protected] > > >> > <mailto:[email protected]>>: > > >> > > > >> > 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 mo= re > > >> > callbacks queued by call_rcu? I need that because there are so= me > > >> > callbacks which call call_rcu, and then calling rcu_barrier on= ce > > >> > isn't enough and I therefore need a way to check if there are > still > > >> > callbacks to wait on before terminating the program. No worrie= s > 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 > > >> > > > > --0000000000001577db063dd7dc69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">> We usually rely on the debugging code in rcu_derefere= nce() to check this<br>> sort of thing.=C2=A0 Or are you worried about t= he 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 "libra= ry" I made checks everything else, if I haven't overlooked anythin= g.</div><div><br></div><div>Thanks</div><div>Thobias</div></div><br><div cl= ass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_a= ttr">tir. 2. sep. 2025 kl. 22:33 skrev Paul E. McKenney <<a href=3D"mail= to:[email protected]">[email protected]</a>>:<br></div><blockquote cla= ss=3D"gmail_quote" style=3D"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 wh= ether<br> > reads are done outside read sections is that you can not make macros f= or<br> > read and write operations. e.g. ptr->a =3D 4;.<br> <br> We usually rely on the debugging code in rcu_dereference() to check this<br= > sort of thing.=C2=A0 Or are you worried about the user leaking RCU-protecte= d<br> pointers out past the rcu_read_unlock()?<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanx, Paul<br> <br> > tir. 2. sep. 2025 kl. 16:17 skrev Thobias Knudsen <<a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</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 with= in 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<b= r> > > rcu_quiescent_state isnt called when thread is offline<br> > ><br> > > > We've added a "rcu_read_ongoing()" API for tha= t purpose to liburcu<br> > > > RCU flavors, but AFAIK it's not used for any kind of val= idation<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 d= ocumentation<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 f= or 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=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</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 fun= ctions 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 DE= BUG_RCU or make<br> > >> > a new one, maybe DEBUG_FUNCTION_CALL_ORDER. The only thi= ng it doesn't<br> > >> > catch is if you continue to use data from cds_lfht_looku= p() after<br> > >> > rcu_read_unlock()<br> > >><br> > >> I suspect that what you are trying to achieve is validation t= hat<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 withi= n 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 vali= dation<br> > >> within cds_lfht. This could indeed become a feature request t= hat<br> > >> would apply to all liburcu data structure APIs.<br> > >><br> > >> Thanks,<br> > >><br> > >> Mathieu<br> > >><br> > >> ><br> > >> > s=C3=B8n. 31. aug. 2025 kl. 22:42 skrev Thobias Knudsen = <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= m</a><br> > >> > <mailto:<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>>>:<br> > >> ><br> > >> >=C2=A0 =C2=A0 =C2=A0First question: why isn't Userspa= ce RCU more popular?<br> > >> >=C2=A0 =C2=A0 =C2=A0Second question: Why isn't it pos= sible to create issues in the urcu<br> > >> >=C2=A0 =C2=A0 =C2=A0repo? Im asking for a feature here:<b= r> > >> >=C2=A0 =C2=A0 =C2=A0Is it possible to make a function whi= ch checks if there are more<br> > >> >=C2=A0 =C2=A0 =C2=A0callbacks queued by call_rcu? I need = that because there are some<br> > >> >=C2=A0 =C2=A0 =C2=A0callbacks which call call_rcu, and th= en calling rcu_barrier once<br> > >> >=C2=A0 =C2=A0 =C2=A0isn't enough and I therefore need= a way to check if there are still<br> > >> >=C2=A0 =C2=A0 =C2=A0callbacks to wait on before terminati= ng the program. No worries if<br> > >> >=C2=A0 =C2=A0 =C2=A0this is too much to ask for or if it = isn't possible. This<br> > >> >=C2=A0 =C2=A0 =C2=A0functionality is only needed in termi= nation because otherwise<br> > >> >=C2=A0 =C2=A0 =C2=A0isn't needed to call rcu_barrier = multiple times (at least so far)<br> > >> ><br> > >> >=C2=A0 =C2=A0 =C2=A0Best regards<br> > >> >=C2=A0 =C2=A0 =C2=A0Thobias<br> > >> ><br> > >> ><br> > >><br> > >><br> > >> --<br> > >> Mathieu Desnoyers<br> > >> EfficiOS Inc.<br> > >> <a href=3D"https://www.efficios.com" rel=3D"noreferrer" targe= t=3D"_blank">https://www.efficios.com</a><br> > >><br> > ><br> </blockquote></div> --0000000000001577db063dd7dc69--