You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
samples: zbus: msg_subscriber: Filter SMP from pool exhaustion tests
The "_too_small" test variants intentionally configure an isolated buffer
pool with only 2 buffers to validate proper error handling when the pool
is exhausted during notification of 16 msg_subscriber observers. These
tests are likely to fail on SMP systems due to a buffer recycling race
condition:
Expected behavior (uniprocessor):
Publisher Thread:
1. Allocate buf1 for bar_msg_sub1 ✓
2. k_fifo_put(sub1_fifo, buf1)
3. Allocate buf2 for bar_msg_sub2 ✓
4. k_fifo_put(sub2_fifo, buf2)
5. Try allocate buf3 for bar_msg_sub3 → FAIL -ENOMEM
Subscriber threads process messages after notification completes,
pool exhausts at subscriber zephyrproject-rtos#3 as expected.
SMP race condition:
CPU 0 (Publisher): CPU 1 (bar_msg_sub1): CPU 2 (bar_msg_sub2):
------------------ --------------------- ---------------------
Alloc buf1 ✓
k_fifo_put(sub1, buf1)
k_fifo_get() → buf1
zbus_sub_wait_msg()
net_buf_unref()
→ buf1 FREED!
Alloc buf2 ✓
(reuses buf1!)
k_fifo_put(sub2, buf2)
k_fifo_get() → buf2
net_buf_unref()
→ buf2 FREED!
Alloc buf3 ✓
(reuses buf1 again!)
...continues...
All 16 allocations succeed!
On SMP systems, subscriber threads on other CPUs may consume and free
buffers quickly enough that they are recycled back to the pool before the
publisher's notification loop can exhaust it. The test's assumption that
notification completes before subscribers run does not hold with parallel
execution.
Since this is a test design limitation (not a zbus bug), filter SMP
configurations from these specific test variants rather than attempt to
artificially slow down subscribers or change thread priorities.
Fixes CI failures on Arm's FVP SMP configurations.
Signed-off-by: Nicolas Pitre <[email protected]>
0 commit comments