From thobknu at gmail.com Tue Sep 2 10:02:28 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Tue, 2 Sep 2025 16:02:28 +0200 Subject: URCU feature request? In-Reply-To: References: Message-ID: > 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thobknu at gmail.com Tue Sep 2 10:17:19 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Tue, 2 Sep 2025 16:17:19 +0200 Subject: URCU feature request? In-Reply-To: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> Message-ID: > 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 > >: > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thobknu at gmail.com Tue Sep 2 10:24:16 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Tue, 2 Sep 2025 16:24:16 +0200 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> Message-ID: 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 : > > 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 > > >: >> > >> > 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulmck at kernel.org Tue Sep 2 16:33:28 2025 From: paulmck at kernel.org (Paul E. McKenney) Date: Tue, 2 Sep 2025 13:33:28 -0700 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> Message-ID: <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> 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 : > > > > 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 >> > >: > >> > > >> > 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 > >> > > From thobknu at gmail.com Tue Sep 2 17:06:08 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Tue, 2 Sep 2025 23:06:08 +0200 Subject: URCU feature request? In-Reply-To: <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> Message-ID: > 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 : > 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 : > > > > > > 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 > > >> > >: > > >> > > > >> > 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 > > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at sury.org Tue Sep 2 17:33:50 2025 From: ondrej at sury.org (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Tue, 2 Sep 2025 23:33:50 +0200 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> Message-ID: 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 at sury.org > On 2. 9. 2025, at 23:06, Thobias Knudsen via lttng-dev 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. > From thobknu at gmail.com Tue Sep 2 17:48:43 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Tue, 2 Sep 2025 23:48:43 +0200 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> Message-ID: 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? : > 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 at sury.org > > > On 2. 9. 2025, at 23:06, Thobias Knudsen via lttng-dev < > lttng-dev at 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. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulmck at kernel.org Tue Sep 2 21:20:32 2025 From: paulmck at kernel.org (Paul E. McKenney) Date: Tue, 2 Sep 2025 18:20:32 -0700 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> Message-ID: 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 : > > > 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 : > > > > > > > > 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 > > > >> > >: > > > >> > > > > >> > 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 > > > >> > > > > > > From odion at efficios.com Tue Sep 2 21:35:16 2025 From: odion at efficios.com (Olivier Dion) Date: Tue, 02 Sep 2025 21:35:16 -0400 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> Message-ID: <87y0qwwc6j.fsf@laura> On Tue, 02 Sep 2025, Thobias Knudsen via lttng-dev 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 From thobknu at gmail.com Thu Sep 4 14:06:26 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Thu, 4 Sep 2025 20:06:26 +0200 Subject: URCU feature request? In-Reply-To: <87y0qwwc6j.fsf@laura> References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> Message-ID: > 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 : > 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: From thobknu at gmail.com Thu Sep 4 14:09:03 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Thu, 4 Sep 2025 20:09:03 +0200 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> Message-ID: > 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 : > > 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 : > >> 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: From odion at efficios.com Fri Sep 5 14:04:21 2025 From: odion at efficios.com (Olivier Dion) Date: Fri, 05 Sep 2025 14:04:21 -0400 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> Message-ID: <87h5xg7p3u.fsf@laura> On Thu, 04 Sep 2025, Thobias Knudsen 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 From thobknu at gmail.com Sun Sep 7 15:18:46 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Sun, 7 Sep 2025 21:18:46 +0200 Subject: URCU feature request? In-Reply-To: <87h5xg7p3u.fsf@laura> References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> <87h5xg7p3u.fsf@laura> Message-ID: > 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 : > On Thu, 04 Sep 2025, Thobias Knudsen 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From odion at efficios.com Sun Sep 7 20:10:57 2025 From: odion at efficios.com (Olivier Dion) Date: Sun, 07 Sep 2025 20:10:57 -0400 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> <87h5xg7p3u.fsf@laura> Message-ID: <87bjnlrege.fsf@laura> On Sun, 07 Sep 2025, Thobias Knudsen 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 From mathieu.desnoyers at efficios.com Mon Sep 8 16:07:55 2025 From: mathieu.desnoyers at efficios.com (Mathieu Desnoyers) Date: Mon, 8 Sep 2025 16:07:55 -0400 Subject: [RELEASE] LTTng-modules 2.13.20 and 2.14.1 (Linux kernel tracer) Message-ID: Hi, This is a stable release announcement for the LTTng kernel tracer, an out-of-tree kernel tracer for the Linux kernel. The LTTng project provides low-overhead, correlated userspace and kernel tracing on Linux. Its use of the Common Trace Format and a flexible control interface allows it to fulfill various workloads. * New in this release: The changes in those releases are mainly kernel enablement updates to allow compiling against recent kernels and building against the full kernel source, which allows building additional instrumentation such as ext4 and btrfs. * Detailed change log 2025-09-08 LTTng modules 2.13.20 * Add missing prototype for wrapper_get_pfnblock_flags_mask() * fix: mm: remove the for_reclaim field from struct writeback_control (v6.17) * fix: btrfs: use refcount_t type for the extent buffer reference counter (v6.17) * fix: percpu: repurpose __percpu tag as a named address space qualifier (v6.15) * tracepoint: Have tracepoints created with DECLARE_TRACE() have _tp suffix (v6.16) * fix: treewide, timers: Rename from_timer() to timer_container_of() (v6.16) * fix: mm/writeback: Convert tracing writeback_page_template to folios (v5.16) * fix: mm/page-writeback: introduce tracepoint for wait_on_page_writeback() (v5.2) * fix: btrfs: use the flags of an extent map to identify the compression type (v6.8) * fix: btrfs: update the writepage tracepoint to take a folio (v6.12) * fix: btrfs: tracepoints: add btrfs prefix to names where it's missing (v6.16) * fix: ext4: Change remaining tracepoints to use folio (v6.5) * fix: ext4: Convert invalidatepage to invalidate_folio (v5.18) * fix: sched/tracepoints: Move and extend the sched_process_exit() tracepoint (v6.16) * Fix: `fast_page_fault` changed in RHEL 8.7 * Fix: `kvm_exit` changed in RHEL 8.7 2025-09-08 LTTng modules 2.14.1 * Add missing prototype for wrapper_get_pfnblock_flags_mask() * fix: mm: remove the for_reclaim field from struct writeback_control (v6.17) * fix: btrfs: use refcount_t type for the extent buffer reference counter (v6.17) * Fix: `fast_page_fault` changed in RHEL 8.7 * Fix: `kvm_exit` changed in RHEL 8.7 * fix: percpu: repurpose __percpu tag as a named address space qualifier (v6.15) * writeback instrumentation: Add missing provider name prefix Enjoy! Mathieu Project website: https://lttng.org Documentation: https://lttng.org/docs Download link: https://lttng.org/download -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com From thobknu at gmail.com Fri Sep 19 16:39:11 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Fri, 19 Sep 2025 22:39:11 +0200 Subject: URCU feature request? In-Reply-To: <87bjnlrege.fsf@laura> References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> <87h5xg7p3u.fsf@laura> <87bjnlrege.fsf@laura> Message-ID: >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 : > On Sun, 07 Sep 2025, Thobias Knudsen 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thobknu at gmail.com Fri Sep 19 16:42:05 2025 From: thobknu at gmail.com (Thobias Knudsen) Date: Fri, 19 Sep 2025 22:42:05 +0200 Subject: URCU feature request? In-Reply-To: References: <3c49eadb-f310-46b2-984d-58a0c193cde9@efficios.com> <2f0dc1b4-3fcb-453c-aa42-4a1f85623300@paulmck-laptop> <87y0qwwc6j.fsf@laura> <87h5xg7p3u.fsf@laura> <87bjnlrege.fsf@laura> Message-ID: I forgot to say Thanks, Thobias fre. 19. sep. 2025 kl. 22:39 skrev Thobias Knudsen : > >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 : > >> On Sun, 07 Sep 2025, Thobias Knudsen 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pikolasikolatest1 at gmail.com Fri Sep 26 13:58:19 2025 From: pikolasikolatest1 at gmail.com (Rabha hssni) Date: Fri, 26 Sep 2025 18:58:19 +0100 Subject: =?UTF-8?B?2KPZgdi22YQgMTAg2YXZiNin2YLYuSDZhNmE2KjYrdirINi52YYg2LnZhdmEINmB2Yog?= =?UTF-8?B?2KfZhNmF2LrYsdioICgyMDI1KQ==?= Message-ID: ???? 10 ????? ????? ?? ??? ?? ?????? (2025) ??? ??? ?????? ?? ???? ????? ????????? ????? ?? ?? ???????? ??????? ?????? ????? ???????? ?? ???? ???? ??????? ?? ?????? ????? ???? ???? ??? ????? ????? ????????? ??????. ???? ??? ??????? ????? ?????? ?? ???? ??????? ?? ?????? ??????? ???? ?? ?????? ????? ?? ??????? ???????? ????? ????? ???? ??? ????? ???????? ??????? ????? ?????. ??? ??? ???? ?? ????? ?? ??? ?? ????? ????? ????? ???????? ??? ???? ??? ???????? ???? ????? ???????? ?? ??? linkedin ???????. ??? ???? ????? ???? ??? ??????? ?????? ????? ??? ????? ????? ????? ?????. ?? ???? ??? ?????? ???????? ????? ?????? ?????? ??? ????? ?????? ??????? ?????? ???? ????? ??????? ??? ?????? ????? ?????? ??? ???? ??????? ???? ?? ???? ??????. 1. TARGIR.c om ? ??? ???? ?????? ????? ??????? ???? ???? TARGIR ?? ???? ????? ????? ??????? ????? ?? ??????? ??? ???? ??? ??? ?????? ?????? ???? ????? ?? ???? ????? ???????? ???????? ??????. ???? ?????? ?????? ??? ????? ????? ???? ??? ????? ???? ?????? ???? ?????? ????? ????? ?????? ??? ?????? ????? ????? ???????? ?? ????? ??? ????? ??? ????? ???????? ?? ??? ?????? ??????? ???????. ???? ??? ???? ?? ????? ?? ?????? ???????? ?? ???? ?? ????? ?? ??? ??????? ?? ??? ????? ???? ?? ????? ??? ??????? ??????? ?? ?????? ????????? ??? TARGIR ???? ?????? ???? ??????. ??? ???? ?? ??????? ??? ????? ??? ???? ??????? ???? ?????? ??????? ???????? ????? ????????? ???? ?????? ?????? ?? ???? ????? ??????? ?? ?????? ???????. ?????? TARGIR: ??????? ????? ????? ?????? ?? ????? ????????. ????? ??????? ???? ?????? ??? ??????? ?? ??????. ????? ?????? ?????? ???? ????? ????????. ??????? ???? ??????? ??????? ??? ??????? ????????. ???? ??? ?????? ??????? ??? ???? ?? ????? ?? ??????? ?????? ?? ?????? ????????? ???????? ???????? ????????. ???? ?????? ????? ?????? ???? ??????? ??????? ?? ????? ???? ??? kpc ?????? maximus ?????? ?ngha ?????? ???????? ??? ??? ??? ???? uep ???????. ??? ???? ?????? ????? ?? ???????? ????? ??????? ?? ??? ????? ?????? ??? ???? ???????? ???? ???? ????? ?? ???????? ??????? ????????? ??????? ??????. ????? ????? ??????? ??? ??????? ??????? ?? ????? ???????? ??? ????? ??????? ???????? ??????? ????? ???? ???????. ???? ?????? ????? ?? ????? ?????? ??? ???????? ?????? ?????? ??????? ???????? ?????? ???? ???????. ??? ???? ?? ?????? ??? ??????? ???????? ?????? ????? ???????? ????? 2022 ?? ????? ???????? ????? ??? ????? ???? ??????. 2. Rekrute ? ??? ??? ?? ???? ??????? ???? Rekrute ?? ???? ????? ????? ??????? ?? ??????. ???? ????? ?? ????? ???? ?? ?????? ??????? ??????? ???? ??? ????? ???????? ???????? ???????. ????? ??: ???????? ?? ?????? ??????? ????????. ???????? ?? ??? ??? ?? ????? ????? ???????? ???????. 3. Emploi.ma ? ???? ??? ?? ?? ???????? Emploi.ma ???? ?????? ???????? ?? ????? ?? ?? ????? ????????. ???? ?? ????? ???? ??? ??? ???????? ???????? ?? ???? ?????. ??????? ?????? ?? ??????? ?? ????? ?? ??? ?? ????????? ?????? ?? ??? ????? ??? ???? ???? ???: "??? ?? ??? ???? ????? ?? ?????? 2022" ?? "???? ?? ??? ?? ???? ?????? ???????". ????? ???? ??????: ??? ??? ????? ?????? ????? ?????? ???? ????? ????? 100 ???? ?????? ????? ???????? 4. Bayt.com ? ????? ????? ??????? ??????? ??? ?? Bayt.com ??????? ???? ???? ?? ????? ??????? ??? ??? ????? ????? ????? ?? ??????? ??????? ?? ??????? ???? ??????? ????????. ?????: ???? ????? ??????? ???????? ?????? ???????? ???? ??? "??????" ?????? ??? ????? ?????. 5. Job.ma ? ???? ????? ?????? ????????? ????? ??? ??? ??? ??????: "???? ?? ??? ?? ????? ???? 2022" ?? "???? ?? ??? ?? ???????"? ??? Job.ma ?? ?????? ?????? ??. ????? ??? ??? ????? ?????? ?????? ????????? ????????? ?????????. 6. LinkedIn ? ???? ???????? ??????? ?? ?????? ?????? LinkedIn ???? ????? ????? ???? ???? ????? ????? ?? ????? ?? ?????? ?????? ??? ??????? ??? ??????? ?? ??????. ????? ?????? ??? ??? ?? ??? ??????? ?? ??????? ?????? ?? ??????? ???????? ???? ???? ?? ???? ?? ??????? ???????. 7. Indeed ? ???? ??? ???? ??????? ?? ???? Indeed ??????? ????? ???? ???? ??????? ???????? ????? ??????? ???: ????? ?? ??? ????? ?? ????? ??? ?? ??? ?? ???? ????? ??????? morocco ????? ?? ?????? ????? ?? ????? ?? ????? ?? ?????? ?????? 8. Anapec ? ??????? ??????? ??????? ????? ???? ??????? ??????? ?????? ??????? ????????? (Anapec) ???? ?????? ?????? ???? ??????? ??????? ???????? ???? ?? ?????? ?????. ???? ??????: ??? ?? ??? ???? ??????. ??????? ?? ?????? ???? ????? 2021 ?2022. 9. Wadifate ? ????? ?????? ?? ??? ?????? ?????? ??? ?????? ?? ???? ??????? ???????? ?? ??? ???? ????? ??????? ?? ??????? ??????? ?????? ?? ??? ???????? ?? ????? ?? ?????? ?????. ???? ?????? ??????? ?????? ?? ??????? ??????? ?? ????? ???????? ??? ????????? ???????? ????????. ????? ???????? ?????? ??? ??? ??? ???? ??????? ??????? ??????? ??????? ???????? ???????? ??? ??? ????? ???? ?? ????? ???? ??? maximus ?????? kpc ?????? ????? ?????. ??? ???? ?????? ?????? ?? ????? ?????? ??? ?????? ??????? ??????? ????????? ?????. ???? ??? ?????? ???? ???? ??? ?? ???? ?? ?????? ??? ??????? ???????? ?????? ????? ???????? ????? 2022? ??? ???? ??? ????? ?????? ??? ??????? ?? ??? ???????? ?? ??????? ??????. ????? ???? ??????: ??? ??? ????? ?????? ??????? ??????? ?????? ?????? ??????????????? ???????? ???? ??? ???? ????? ?????? ???????? ?? ????????? ?????????? 10. MarocAnnonces ? ??????? ???? ???? ??????? ??? ??? ???? ??????? ????? ??? ?? MarocAnnonces ????? ??? ??? ??? ?? ??????? ?????? ??? ???? ???????? ???????? ??: ??? ?? ??? ???? ?? ???? ?? ?????. ??? ?? ??? ?? ???? ?????? ?? ??????. ???? ?? ??? ?? ?????? ?????. ??????? ??????? ??? ????? ?? ??? ?? ?????? *?? ?? ???? ????? ????? ?? ????? ?? ???????* ?????? ??????: 1. TARGIR.c om ? ??? ???? ?????? ????? ??????? * ?? ?????? ????? ????? ???? ????? ?? ???????* ???? ???? ?????? ?? ??? ????? ?? ?????? ???? ?????? ?????? ?? ?????? ?????? ?????? ????????. *??? ???? ?? ??? ?? ?????? ???? ?? ?????* ?????? ????? ??? Job.ma ?MarocAnnonces? ????? ?????? ???: "??? ?? ??? ???? ?? ????? ???????" ?? "??? ?? ??? ???? ?????? ??????". ????? ?? ?? ?? ???????? ???? ?????? ????? ????? ?? ??? ?? ??????? ??? ????? ???? ????? ????? ????? ???? ???? ??? ??? ?????? ?????? ??????. ???? ??? ???? ?? ????? ?? ?????? ?? ??? ?? ????? ?? ??? ????? ?? ????? ?? ????? ???????? ????? ????? TARGIR.c om ?? ???? ???? ??? ??????? ?????? ?? ??? ???????. ?? ????? ??????? ?? ???? ???? ?????. ???? ?????? ????????? ???? ????? ???????? ??? ??????? ?? ???? ????? ?? ??????! -------------- next part -------------- An HTML attachment was scrubbed... URL: