Commit | Line | Data |
---|---|---|
d001c886 MJ |
1 | <!-- |
2 | SPDX-FileCopyrightText: 2023 EfficiOS Inc. | |
3 | ||
4 | SPDX-License-Identifier: CC-BY-4.0 | |
5 | --> | |
6 | ||
d589a916 PP |
7 | Userspace RCU Implementation |
8 | ============================ | |
9 | ||
10 | by Mathieu Desnoyers and Paul E. McKenney | |
11 | ||
12 | ||
13 | Building | |
14 | -------- | |
15 | ||
16 | ./bootstrap # skip if using tarball | |
17 | ./configure | |
18 | make | |
19 | make install | |
20 | ldconfig | |
21 | ||
22 | Hints: | |
23 | ||
24 | - Forcing 32-bit build: | |
25 | ||
26 | CFLAGS="-m32 -g -O2" ./configure | |
27 | ||
28 | - Forcing 64-bit build: | |
29 | ||
30 | CFLAGS="-m64 -g -O2" ./configure | |
31 | ||
32 | - Forcing a 32-bit build with 386 backward compatibility: | |
33 | ||
34 | CFLAGS="-m32 -g -O2" ./configure --host=i386-pc-linux-gnu | |
35 | ||
36 | - Forcing a 32-bit build for Sparcv9 (typical for Sparc v9) | |
37 | ||
38 | CFLAGS="-m32 -Wa,-Av9a -g -O2" ./configure | |
39 | ||
40 | ||
41 | Architectures supported | |
42 | ----------------------- | |
43 | ||
44 | Currently, the following architectures are supported: | |
45 | ||
f328865f | 46 | - x86 (i386, i486, i586, i686) |
72886af7 | 47 | - amd64 / x86\_64 |
d589a916 PP |
48 | - PowerPC 32/64 |
49 | - S390, S390x | |
50 | - ARM 32/64 | |
51 | - MIPS | |
859050b3 | 52 | - NIOS2 |
d589a916 PP |
53 | - Alpha |
54 | - ia64 | |
55 | - Sparcv9 32/64 | |
56 | - Tilera | |
57 | - hppa/PA-RISC | |
f328865f MD |
58 | - m68k |
59 | - RISC-V | |
60 | ||
61 | Tested on: | |
62 | ||
63 | - Linux all architectures | |
0966bbf4 | 64 | - FreeBSD 13 i386/amd64 |
f328865f | 65 | - Cygwin i386/amd64 |
0af4b40c | 66 | - MacOS amd64/arm64 |
d589a916 | 67 | |
d589a916 PP |
68 | Should also work on: |
69 | ||
70 | - Android | |
71 | - NetBSD 5 | |
72 | - OpenBSD | |
1320034b | 73 | - Solaris |
d589a916 PP |
74 | |
75 | (more testing needed before claiming support for these OS). | |
76 | ||
d589a916 | 77 | |
d2916ca5 YN |
78 | Toolchain support |
79 | ----------------- | |
4d1f67b9 | 80 | |
d2916ca5 YN |
81 | The C compiler used needs to support at least C99. The C++ compiler used needs |
82 | to support at least C++11. The oldest GCC version officialy supported and | |
83 | tested is 4.8. | |
84 | ||
85 | Older GCC versions might still work with the following exceptions: | |
d589a916 PP |
86 | |
87 | - GCC 3.3 and 3.4 have a bug that prevents them from generating volatile | |
88 | accesses to offsets in a TLS structure on 32-bit x86. These versions are | |
89 | therefore not compatible with `liburcu` on x86 32-bit | |
90 | (i386, i486, i586, i686). | |
91 | The problem has been reported to the GCC community: | |
efa4515d | 92 | <http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg281255.html> |
d589a916 | 93 | - GCC 3.3 cannot match the "xchg" instruction on 32-bit x86 build. |
efa4515d | 94 | See <http://kerneltrap.org/node/7507> |
d589a916 PP |
95 | - Alpha, ia64 and ARM architectures depend on GCC 4.x with atomic builtins |
96 | support. For ARM this was introduced with GCC 4.4: | |
efa4515d | 97 | <http://gcc.gnu.org/gcc-4.4/changes.html>. |
ddec79fd MD |
98 | - Linux aarch64 depends on GCC 5.1 or better because prior versions |
99 | perform unsafe access to deallocated stack. | |
d589a916 PP |
100 | |
101 | Clang version 3.0 (based on LLVM 3.0) is supported. | |
102 | ||
ef6da886 MJ |
103 | Glibc >= 2.4 should work but the older version we test against is |
104 | currently 2.17. | |
105 | ||
d2916ca5 YN |
106 | |
107 | Build system | |
108 | ------------ | |
109 | ||
d589a916 PP |
110 | For developers using the Git tree: |
111 | ||
112 | This source tree is based on the autotools suite from GNU to simplify | |
113 | portability. Here are some things you should have on your system in order to | |
114 | compile the git repository tree : | |
115 | ||
afb6113f | 116 | - GNU autotools (automake >=1.12, autoconf >=2.69) |
d589a916 PP |
117 | (make sure your system wide `automake` points to a recent version!) |
118 | - GNU Libtool >=2.2 | |
efa4515d | 119 | (for more information, go to <http://www.gnu.org/software/autoconf/>) |
d589a916 PP |
120 | |
121 | If you get the tree from the repository, you will need to use the `bootstrap` | |
122 | script in the root of the tree. It calls all the GNU tools needed to prepare | |
123 | the tree configuration. | |
124 | ||
125 | Test scripts provided in the `tests/` directory of the source tree depend | |
126 | on `bash` and the `seq` program. | |
127 | ||
128 | ||
129 | API | |
130 | --- | |
131 | ||
132 | See the relevant API documentation files in `doc/`. The APIs provided by | |
133 | Userspace RCU are, by prefix: | |
134 | ||
dcb9c05a | 135 | - `rcu_`: Read-Copy Update (see [`doc/rcu-api.md`](doc/rcu-api.md)) |
d589a916 PP |
136 | - `cmm_`: Concurrent Memory Model |
137 | - `caa_`: Concurrent Architecture Abstraction | |
138 | - `cds_`: Concurrent Data Structures | |
dcb9c05a | 139 | (see [`doc/cds-api.md`](doc/cds-api.md)) |
d589a916 | 140 | - `uatomic_`: Userspace Atomic |
dcb9c05a | 141 | (see [`doc/uatomic-api.md`](doc/uatomic-api.md)) |
d589a916 PP |
142 | |
143 | ||
144 | Quick start guide | |
145 | ----------------- | |
146 | ||
147 | ### Usage of all urcu libraries: | |
148 | ||
149 | - Define `_LGPL_SOURCE` (only) if your code is LGPL or GPL compatible | |
150 | before including the `urcu.h` or `urcu-qsbr.h` header. If your application | |
151 | is distributed under another license, function calls will be generated | |
152 | instead of inlines, so your application can link with the library. | |
153 | - Linking with one of the libraries below is always necessary even for | |
154 | LGPL and GPL applications. | |
155 | - Define `URCU_INLINE_SMALL_FUNCTIONS` before including Userspace RCU | |
156 | headers if you want Userspace RCU to inline small functions (10 | |
157 | lines or less) into the application. It can be used by applications | |
158 | distributed under any kind of license, and does *not* make the | |
159 | application a derived work of Userspace RCU. | |
160 | ||
161 | Those small inlined functions are guaranteed to match the library | |
162 | content as long as the library major version is unchanged. | |
163 | Therefore, the application *must* be compiled with headers matching | |
164 | the library major version number. Applications using | |
165 | `URCU_INLINE_SMALL_FUNCTIONS` may be unable to use debugging | |
166 | features of Userspace RCU without being recompiled. | |
167 | ||
f328865f MD |
168 | There are multiple flavors of liburcu available: |
169 | ||
170 | - `memb`, | |
171 | - `qsbr`, | |
172 | - `mb`, | |
173 | - `signal`, | |
174 | - `bp`. | |
175 | ||
72886af7 WY |
176 | The API members start with the prefix `urcu_<flavor>_`, where |
177 | `<flavor>` is the chosen flavor name. | |
f328865f | 178 | |
d589a916 | 179 | |
f328865f | 180 | ### Usage of `liburcu-memb` |
d589a916 | 181 | |
f328865f MD |
182 | 1. `#include <urcu/urcu-memb.h>` |
183 | 2. Link the application with `-lurcu-memb` | |
d589a916 PP |
184 | |
185 | This is the preferred version of the library, in terms of | |
186 | grace-period detection speed, read-side speed and flexibility. | |
187 | Dynamically detects kernel support for `sys_membarrier()`. Falls back | |
188 | on `urcu-mb` scheme if support is not present, which has slower | |
cef5f31d | 189 | read-side. Use the `--disable-sys-membarrier-fallback` configure option |
d8d9a340 MD |
190 | to disable the fall back, thus requiring `sys_membarrier()` to be |
191 | available. This gives a small speedup when `sys_membarrier()` is | |
192 | supported by the kernel, and aborts in the library constructor if not | |
193 | supported. | |
d589a916 PP |
194 | |
195 | ||
196 | ### Usage of `liburcu-qsbr` | |
197 | ||
f328865f | 198 | 1. `#include <urcu/urcu-qsbr.h>` |
d589a916 PP |
199 | 2. Link with `-lurcu-qsbr` |
200 | ||
201 | The QSBR flavor of RCU needs to have each reader thread executing | |
202 | `rcu_quiescent_state()` periodically to progress. `rcu_thread_online()` | |
203 | and `rcu_thread_offline()` can be used to mark long periods for which | |
204 | the threads are not active. It provides the fastest read-side at the | |
205 | expense of more intrusiveness in the application code. | |
206 | ||
207 | ||
208 | ### Usage of `liburcu-mb` | |
209 | ||
f328865f MD |
210 | 1. `#include <urcu/urcu-mb.h>` |
211 | 2. Link with `-lurcu-mb` | |
d589a916 PP |
212 | |
213 | This version of the urcu library uses memory barriers on the writer | |
214 | and reader sides. This results in faster grace-period detection, but | |
215 | results in slower reads. | |
216 | ||
217 | ||
218 | ### Usage of `liburcu-signal` | |
219 | ||
f328865f MD |
220 | 1. `#include <urcu/urcu-signal.h>` |
221 | 2. Link the application with `-lurcu-signal` | |
d589a916 | 222 | |
97d13221 OD |
223 | NOTE: The `liburcu-signal` flavor is *deprecated* and will be removed in the |
224 | future. It is now identical to `liburcu-mb` at the exception of the symbols and | |
225 | public header files. It is therefore slower than previous versions. Users are | |
226 | encouraged to migrate to the `liburcu-memb` flavor. | |
d589a916 PP |
227 | |
228 | ### Usage of `liburcu-bp` | |
229 | ||
f328865f | 230 | 1. `#include <urcu/urcu-bp.h>` |
d589a916 PP |
231 | 2. Link with `-lurcu-bp` |
232 | ||
233 | The BP library flavor stands for "bulletproof". It is specifically | |
234 | designed to help tracing library to hook on applications without | |
5b46e39d MD |
235 | requiring to modify these applications. `urcu_bp_init()`, and |
236 | `urcu_bp_unregister_thread()` all become nops, whereas calling | |
237 | `urcu_bp_register_thread()` becomes optional. The state is dealt with by | |
238 | the library internally at the expense of read-side and write-side | |
239 | performance. | |
d589a916 PP |
240 | |
241 | ||
242 | ### Initialization | |
243 | ||
244 | Each thread that has reader critical sections (that uses | |
f328865f MD |
245 | `urcu_<flavor>_read_lock()`/`urcu_<flavor>_read_unlock()` must first |
246 | register to the URCU library. This is done by calling | |
247 | `urcu_<flavor>_register_thread()`. Unregistration must be performed | |
248 | before exiting the thread by using `urcu_<flavor>_unregister_thread()`. | |
d589a916 PP |
249 | |
250 | ||
251 | ### Reading | |
252 | ||
253 | Reader critical sections must be protected by locating them between | |
f328865f MD |
254 | calls to `urcu_<flavor>_read_lock()` and `urcu_<flavor>_read_unlock()`. |
255 | Inside that lock, `rcu_dereference()` may be called to read an RCU | |
256 | protected pointer. | |
d589a916 PP |
257 | |
258 | ||
259 | ### Writing | |
260 | ||
261 | `rcu_assign_pointer()` and `rcu_xchg_pointer()` may be called anywhere. | |
f328865f MD |
262 | After, `urcu_<flavor>_synchronize_rcu()` must be called. When it |
263 | returns, the old values are not in usage anymore. | |
d589a916 | 264 | |
111bda8f MD |
265 | As an alternative to `urcu_<flavor>_synchronize_rcu()`, |
266 | it is also possible to use the urcu polling mechanism to wait for a | |
267 | grace period to elapse. This can be done by using | |
268 | `urcu_<flavor>_start_poll_synchronize_rcu()` | |
269 | to start the grace period polling, and then invoke | |
270 | `urcu_<flavor>_poll_state_synchronize_rcu()`, which returns true if | |
271 | the grace period has completed, false otherwise. | |
272 | ||
d589a916 PP |
273 | |
274 | ### Usage of `liburcu-defer` | |
275 | ||
f328865f | 276 | - Follow instructions for either `liburcu-memb`, `liburcu-qsbr`, |
d589a916 PP |
277 | `liburcu-mb`, `liburcu-signal`, or `liburcu-bp` above. |
278 | The `liburcu-defer` functionality is pulled into each of | |
279 | those library modules. | |
f328865f MD |
280 | - Provides `urcu_<flavor>_defer_rcu()` primitive to enqueue delayed |
281 | callbacks. Queued callbacks are executed in batch periodically after | |
282 | a grace period. Do _not_ use `urcu_<flavor>_defer_rcu()` within a | |
283 | read-side critical section, because it may call | |
284 | `urcu_<flavor>_synchronize_rcu()` if the thread queue is full. This | |
285 | can lead to deadlock or worse. | |
286 | - Requires that `urcu_<flavor>_defer_barrier()` must be called in | |
287 | library destructor if a library queues callbacks and is expected to | |
288 | be unloaded with `dlclose()`. | |
d589a916 PP |
289 | |
290 | Its API is currently experimental. It may change in future library releases. | |
291 | ||
292 | ||
293 | ### Usage of `urcu-call-rcu` | |
294 | ||
f328865f | 295 | - Follow instructions for either `liburcu-memb`, `liburcu-qsbr`, |
d589a916 PP |
296 | `liburcu-mb`, `liburcu-signal`, or `liburcu-bp` above. |
297 | The `urcu-call-rcu` functionality is pulled into each of | |
298 | those library modules. | |
f328865f MD |
299 | - Provides the `urcu_<flavor>_call_rcu()` primitive to enqueue delayed |
300 | callbacks in a manner similar to `urcu_<flavor>_defer_rcu()`, but | |
301 | without ever delaying for a grace period. On the other hand, | |
302 | `urcu_<flavor>_call_rcu()`'s best-case overhead is not quite as good | |
303 | as that of `urcu_<flavor>_defer_rcu()`. | |
304 | - Provides `urcu_<flavor>_call_rcu()` to allow asynchronous handling | |
305 | of RCU grace periods. A number of additional functions are provided | |
306 | to manage the helper threads used by `urcu_<flavor>_call_rcu()`, but | |
307 | reasonable defaults are used if these additional functions are not | |
308 | invoked. See [`doc/rcu-api.md`](doc/rcu-api.md) in userspace-rcu | |
309 | documentation for more details. | |
d589a916 PP |
310 | |
311 | ||
312 | ### Being careful with signals | |
313 | ||
f328865f | 314 | The `liburcu-signal` library uses signals internally. The signal handler is |
d589a916 PP |
315 | registered with the `SA_RESTART` flag. However, these signals may cause |
316 | some non-restartable system calls to fail with `errno = EINTR`. Care | |
317 | should be taken to restart system calls manually if they fail with this | |
318 | error. A list of non-restartable system calls may be found in | |
f328865f | 319 | `signal(7)`. |
d589a916 PP |
320 | |
321 | Read-side critical sections are allowed in a signal handler, | |
f328865f | 322 | except those setup with `sigaltstack(2)`, with `liburcu-memb` and |
d589a916 | 323 | `liburcu-mb`. Be careful, however, to disable these signals |
f328865f MD |
324 | between thread creation and calls to `urcu_<flavor>_register_thread()`, |
325 | because a signal handler nesting on an unregistered thread would not be | |
326 | allowed to call `urcu_<flavor>_read_lock()`. | |
d589a916 PP |
327 | |
328 | Read-side critical sections are _not_ allowed in a signal handler with | |
329 | `liburcu-qsbr`, unless signals are disabled explicitly around each | |
f328865f MD |
330 | `urcu_qsbr_quiescent_state()` calls, when threads are put offline and around |
331 | calls to `urcu_qsbr_synchronize_rcu()`. Even then, we do not recommend it. | |
d589a916 PP |
332 | |
333 | ||
334 | ### Interaction with mutexes | |
335 | ||
336 | One must be careful to do not cause deadlocks due to interaction of | |
f328865f MD |
337 | `urcu_<flavor>_synchronize_rcu()` and RCU read-side with mutexes. If |
338 | `urcu_<flavor>_synchronize_rcu()` is called with a mutex held, this | |
339 | mutex (or any mutex which has this mutex in its dependency chain) should | |
340 | not be acquired from within a RCU read-side critical section. | |
d589a916 PP |
341 | |
342 | This is especially important to understand in the context of the | |
343 | QSBR flavor: a registered reader thread being "online" by | |
344 | default should be considered as within a RCU read-side critical | |
345 | section unless explicitly put "offline". Therefore, if | |
f328865f MD |
346 | `urcu_qsbr_synchronize_rcu()` is called with a mutex held, this mutex, |
347 | as well as any mutex which has this mutex in its dependency chain should | |
348 | only be taken when the RCU reader thread is "offline" (this can be | |
349 | performed by calling `urcu_qsbr_thread_offline()`). | |
d589a916 PP |
350 | |
351 | ||
352 | ### Interaction with `fork()` | |
353 | ||
354 | Special care must be taken for applications performing `fork()` without | |
355 | any following `exec()`. This is caused by the fact that Linux only clones | |
356 | the thread calling `fork()`, and thus never replicates any of the other | |
357 | parent thread into the child process. Most `liburcu` implementations | |
358 | require that all registrations (as reader, `defer_rcu` and `call_rcu` | |
359 | threads) should be released before a `fork()` is performed, except for the | |
360 | rather common scenario where `fork()` is immediately followed by `exec()` in | |
361 | the child process. The only implementation not subject to that rule is | |
362 | `liburcu-bp`, which is designed to handle `fork()` by calling | |
f328865f MD |
363 | `urcu_bp_before_fork`, `urcu_bp_after_fork_parent` and |
364 | `urcu_bp_after_fork_child`. | |
365 | ||
366 | Applications that use `urcu_<flavor>_call_rcu()` and that `fork()` | |
367 | without doing an immediate `exec()` must take special action. The | |
368 | parent must invoke `urcu_<flavor>_call_rcu_before_fork()` before the | |
369 | `fork()` and `urcu_<flavor>_call_rcu_after_fork_parent()` after the | |
370 | `fork()`. The child process must invoke | |
371 | `urcu_<flavor>_call_rcu_after_fork_child()`. Even though these three | |
372 | APIs are suitable for passing to `pthread_atfork()`, use of | |
373 | `pthread_atfork()` is **STRONGLY DISCOURAGED** for programs calling the | |
374 | glibc memory allocator (`malloc()`, `calloc()`, `free()`, ...) within | |
375 | `urcu_<flavor>_call_rcu` callbacks. This is due to limitations in the | |
376 | way glibc memory allocator handles calls to the memory allocator from | |
377 | concurrent threads while the `pthread_atfork()` handlers are executing. | |
d589a916 PP |
378 | |
379 | Combining e.g.: | |
380 | ||
f328865f MD |
381 | - call to `free()` from callbacks executed within |
382 | `urcu_<flavor>_call_rcu` worker threads, | |
383 | - executing `urcu_<flavor>_call_rcu` atfork handlers within the glibc | |
384 | pthread atfork mechanism, | |
d589a916 PP |
385 | |
386 | will sometimes trigger interesting process hangs. This usually | |
387 | hangs on a memory allocator lock within glibc. | |
388 | ||
389 | ||
390 | ### Thread Local Storage (TLS) | |
391 | ||
392 | Userspace RCU can fall back on `pthread_getspecific()` to emulate | |
393 | TLS variables on systems where it is not available. This behavior | |
394 | can be forced by specifying `--disable-compiler-tls` as configure | |
395 | argument. | |
396 | ||
397 | ||
d4e640c0 | 398 | ### Usage of `DEBUG_RCU` & `--enable-rcu-debug` |
d589a916 | 399 | |
d4e640c0 JR |
400 | By default the library is configured with internal debugging |
401 | self-checks disabled. | |
402 | ||
403 | For always-on debugging self-checks: | |
af9254ab WY |
404 | |
405 | ./configure --enable-rcu-debug | |
d4e640c0 JR |
406 | |
407 | For fine grained enabling of debugging self-checks, build | |
72886af7 WY |
408 | userspace-rcu with `DEBUG_RCU` defined and compile dependent |
409 | applications with `DEBUG_RCU` defined when necessary. | |
d4e640c0 JR |
410 | |
411 | Warning: Enabling this feature result in a performance penalty. | |
d589a916 PP |
412 | |
413 | ||
414 | ### Usage of `DEBUG_YIELD` | |
415 | ||
416 | `DEBUG_YIELD` is used to add random delays in the code for testing | |
417 | purposes. | |
418 | ||
419 | ||
420 | ### SMP support | |
421 | ||
422 | By default the library is configured to use synchronization primitives | |
423 | adequate for SMP systems. On uniprocessor systems, support for SMP | |
424 | systems can be disabled with: | |
425 | ||
426 | ./configure --disable-smp-support | |
427 | ||
428 | theoretically yielding slightly better performance. | |
429 | ||
430 | ||
d7c76f85 MD |
431 | ### Usage of `--enable-cds-lfht-iter-debug` |
432 | ||
433 | By default the library is configured with extra debugging checks for | |
434 | lock-free hash table iterator traversal disabled. | |
435 | ||
cef5f31d | 436 | Building liburcu with `--enable-cds-lfht-iter-debug` and rebuilding |
d7c76f85 MD |
437 | application to match the ABI change allows finding cases where the hash |
438 | table iterator is re-purposed to be used on a different hash table while | |
439 | still being used to iterate on a hash table. | |
440 | ||
441 | This option alters the rculfhash ABI. Make sure to compile both library | |
442 | and application with matching configuration. | |
443 | ||
3afcf5a0 OD |
444 | ### Usage of `--enable-compiler-atomic-builtins` |
445 | ||
446 | Building liburcu with `--enable-compiler-atomic-builtins` implements the uatomic | |
447 | API with the compiler atomic builtins if supported. | |
d7c76f85 | 448 | |
d589a916 PP |
449 | Make targets |
450 | ------------ | |
451 | ||
452 | In addition to the usual `make check` target, Userspace RCU features | |
ff59d427 | 453 | `make regtest`, `make short_bench` and `make long_bench` targets: |
d589a916 PP |
454 | |
455 | - `make check`: short tests, meant to be run when rebuilding or | |
456 | porting Userspace RCU. | |
457 | - `make regtest`: long (many hours) test, meant to be run when | |
458 | modifying Userspace RCU or porting it to a new architecture or | |
459 | operating system. | |
ff59d427 STH |
460 | - `make short_bench`: short benchmarks, 3 seconds per test. |
461 | - `make long_bench`: long (many hours) benchmarks, 30 seconds per test. | |
d589a916 PP |
462 | |
463 | ||
43f53c96 MD |
464 | Known issues |
465 | ------------ | |
466 | ||
467 | There is an application vs library compatibility issue between | |
468 | applications built using Userspace RCU 0.10 headers linked against | |
469 | Userspace RCU 0.11 or 0.12 shared objects. The problem occurs as | |
470 | follows: | |
471 | ||
72886af7 | 472 | - An application executable is built with `_LGPL_SOURCE` defined, includes |
43f53c96 | 473 | any of the Userspace RCU 0.10 urcu flavor headers, and is built |
cef5f31d | 474 | without the `-fpic` compiler option. |
43f53c96 MD |
475 | |
476 | - The Userspace RCU 0.10 library shared objects are updated to 0.11 | |
477 | or 0.12 without rebuilding the application. | |
478 | ||
479 | - The application will hang, typically when RCU grace period | |
480 | (synchronize_rcu) is invoked. | |
481 | ||
482 | Some possible work-arounds for this are: | |
483 | ||
484 | - Rebuild the application against Userspace RCU 0.11+. | |
485 | ||
cef5f31d | 486 | - Rebuild the application with `-fpic`. |
43f53c96 MD |
487 | |
488 | - Upgrade Userspace RCU to 0.13+ without installing 0.11 nor 0.12. | |
489 | ||
490 | ||
d589a916 PP |
491 | Contacts |
492 | -------- | |
493 | ||
494 | You can contact the maintainers on the following mailing list: | |
dcb9c05a | 495 | `lttng-dev@lists.lttng.org`. |