On Sun, 07 Sep 2025, Thobias Knudsen <thob...@gmail.com> 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
