lp:~lttng/urcu/trunk

Branch merges

This import branch has no branches proposed for merge into it.

No branches dependent on this one.

Related source package recipes

1 recipe using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

1486. By Sam James <email address hidden> on 2023-11-06

Fix -Walloc-size

GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
workqueue.c:401:20: warning: allocation of insufficient size '1' for type 'struct urcu_workqueue_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
workqueue.c:432:14: warning: allocation of insufficient size '1' for type 'struct urcu_workqueue_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:912:20: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion' with size '16' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
urcu-call-rcu-impl.h:927:22: warning: allocation of insufficient size '1' for type 'struct call_rcu_completion_work' with size '24' [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
qsbr.c:49:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
mb.c:50:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
membarrier.c:50:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
signal.c:49:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
bp.c:49:14: warning: allocation of insufficient size ‘1’ for type ‘struct mynode’ with size ‘40’ [-Walloc-size[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size]]
```

The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```

So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
doing anything wrong.

Signed-off-by: Sam James <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: Id84ce5cf9a1b97bfa942597aa188ef6e27e7c10d

1485. By Michael Jeanson <email address hidden> on 2023-10-19

cleanup: use an enum for the error states of nr_cpus_mask

Using an enum with labels for error states instead of literal values
will make the code easier to read and understand.

Change-Id: I4558e17ccb45ab40515bb516af840b2852ee8fc3
Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1484. By Michael Jeanson <email address hidden> on 2023-10-03

fix: add missing SPDX licensing tags

Change-Id: If7016a3c83211e88c102f8b395dc290859af4789
Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1483. By Olivier Dion <email address hidden> on 2023-10-02

urcu/uatomic/riscv: Mark RISC-V as broken

Implementations of some atomic operations of GCC for RISC-V are
insufficient for sequential consistency. For this reason Userspace RCU
is currently marked as `broken' for RISC-V with GCC. However, it is
still possible to use other toolchains.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831 for details.

For now, we mark every version of GCC as unsupported. Distribution
package maintainers will have to cherry-pick the relevant patches in GCC
then remove the #error in Userspace RCU if they want to support it.

As for us, we will incrementally add specific versions of GCC that have
fixed the issue whenever new stable releases are made from the GCC
project.

Change-Id: I2cd7c8f12068628b845a096e03f5f8100eacbe43
Signed-off-by: Olivier Dion <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1482. By Jérémie Galarneau <email address hidden> on 2023-09-30

Fix: urcu-bp: misaligned reader accesses

This is a port from a fix in LTTng-UST's embedded urcu (d1a0fad8). The
original message follows:

    Running the LTTng-tools tests (test_valid_filter, for example) under
    address sanitizer results in the following warning:

      /usr/include/lttng/urcu/static/urcu-ust.h:155:6: runtime error: member access within misaligned address 0x7fc45db3a020 for type 'struct lttng_ust_urcu_reader', which requires 128 byte alignment
      0x7fc45db3a020: note: pointer points here
       c4 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    ^

    While the node member of lttng_ust_urcu_reader has an "aligned"
    attribute of CAA_CACHE_LINE_SIZE, the compiler can't ensure the
    alignment of members for dynamically allocated instances.

    The `data` pointer is changed from char* to struct
    lttng_ust_urcu_reader*, allowing the compiler to enforce the expected
    alignment constraints.

    Since `data` was addressed in bytes, the code using this field is
    adapted to use element counts. As the chunks are only used to allocate
    reader instances (and not other types), it makes the code a bit easier
    to read.

Signed-off-by: Jérémie Galarneau <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I89ea1c32ca3c5c45621b562ab68f47a8428d3574

1481. By Olivier Dion <email address hidden> on 2023-09-23

rculfhash: Only pass integral types to atomic builtins

Clang expects the pointers passed to atomic builtins to be integral. Fix
this by casting nodes address to uintptr_t *.

Change-Id: Ifb8833c493df849a542a22f0bb2baeeb85be0297
Signed-off-by: Olivier Dion <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

1480. By Mathieu Desnoyers on 2023-09-06

LoongArch: Document that byte and short atomics are implemented with LL/SC

Based on the LoongArch Reference Manual:

https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html

Section 2.2.7 "Atomic Memory Access Instructions" only lists atomic
operations for 32-bit and 64-bit integers. As detailed in Section
2.2.7.1, LL/SC instructions operating on 32-bit and 64-bit integers are
also available. Those are used by the compiler to support atomics on
byte and short types.

This means atomics on 32-bit and 64-bit types have stronger forward
progress guarantees than those operating on 8-bit and 16-bit types.

Link: https://github.com/urcu/userspace-rcu/pull/11#issuecomment-1706528796
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I01569b718f7300a46d984c34065c0bbfbd2f7cc6

1479. By Wang Jing <email address hidden> on 2023-09-06

Add LoongArch support

This commit completes LoongArch support.

LoongArch supports byte and short atomic operations,
and defines UATOMIC_HAS_ATOMIC_BYTE and UATOMIC_HAS_ATOMIC_SHORT.

Signed-off-by: Wang Jing <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I335e654939bfc90994275f2a4fad550c95f3eba4

1478. By Mathieu Desnoyers on 2023-09-03

Tests: Add test for byte/short atomics on addresses which are not word-aligned

Add a unit test to catch architectures which do not allow byte and short
atomic operations on addresses which are not word aligned.

If an architecture supports byte and short atomic operations, it should
be valid to issue those operations on variables which are not
word-aligned, otherwise the architecture should not define
UATOMIC_HAS_ATOMIC_BYTE nor UATOMIC_HAS_ATOMIC_SHORT.

This should help identify architectures which mistakenly define
UATOMIC_HAS_ATOMIC_BYTE and UATOMIC_HAS_ATOMIC_SHORT.

Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I13d2f3be41749b018b39499106938b3746c419c1

1477. By Mathieu Desnoyers on 2023-08-21

Complete removal of urcu-signal flavor

This commit completes removal of the urcu-signal flavor.

Users can migrate to liburcu-memb with a kernel implementing the
membarrier(2) system call to have similar read-side performance without
requiring use of a reserved signal, and with improved grace period
performance.

Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I75b9171e705b9b2ef4c8eeabe6164e5587816fb4