CI: Test checkpatch #3
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
recheck |
3 similar comments
|
recheck |
|
recheck |
|
recheck |
Signed-off-by: Tyler Baker <[email protected]>
This was referenced Sep 23, 2017
Merged
nagineni
pushed a commit
to nagineni/zephyr
that referenced
this pull request
Nov 20, 2017
…ect-rtos#493) * [scripts] New script 'trlite' to run Travis tests locally With no args, runs all the tests. "trlite zephyr" runs just the VM zephyrproject-rtos#1 "zephyr" tests. "trlite linux" runs just the VM zephyrproject-rtos#2 "linux" tests. "trlite ashell" runs just the VM zephyrproject-rtos#3 "ashell" tests. You can also just pass the VM# instead (1, 2, or 3). Signed-off-by: Geoff Gustafson <[email protected]> * [trlite] Add -v flag for verbose output, change to off by default Signed-off-by: Geoff Gustafson <[email protected]>
nagineni
pushed a commit
to nagineni/zephyr
that referenced
this pull request
Nov 20, 2017
…roject-rtos#907) The check target calls trlite with a new -l flag that makes it run on the current ZJS_BASE source tree w/o doing a git clone for a clean tree. The quickcheck calls trlite on just the Linux tests (VM zephyrproject-rtos#3). Signed-off-by: Geoff Gustafson <[email protected]>
locomuco
added a commit
to locomuco/zephyr
that referenced
this pull request
Jan 12, 2018
boards: tado_ru02xx: fix NFCT config and flash page API
swkim101
added a commit
to swkim101/zephyr
that referenced
this pull request
Oct 24, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.
==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68
READ of size 2 at 0x000000ad81c2 thread T6
#0 0x5279b2 (/root/zephyr.exe+0x5279b2)
zephyrproject-rtos#1 0x4d697d (/root/zephyr.exe+0x4d697d)
zephyrproject-rtos#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192)
zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T2 created by T1 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192)
zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T1 created by T0 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
zephyrproject-rtos#1 0x52f36c (/root/zephyr.exe+0x52f36c)
zephyrproject-rtos#2 0x5371dc (/root/zephyr.exe+0x5371dc)
zephyrproject-rtos#3 0x5312a6 (/root/zephyr.exe+0x5312a6)
zephyrproject-rtos#4 0x52ed7b (/root/zephyr.exe+0x52ed7b)
zephyrproject-rtos#5 0x52eddd (/root/zephyr.exe+0x52eddd)
zephyrproject-rtos#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
==5==ABORTING
Signed-off-by: Sungwoo Kim <[email protected]>
aescolar
pushed a commit
that referenced
this pull request
Oct 25, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.
==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68
READ of size 2 at 0x000000ad81c2 thread T6
#0 0x5279b2 (/root/zephyr.exe+0x5279b2)
#1 0x4d697d (/root/zephyr.exe+0x4d697d)
#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T2 created by T1 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T1 created by T0 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x52f36c (/root/zephyr.exe+0x52f36c)
#2 0x5371dc (/root/zephyr.exe+0x5371dc)
#3 0x5312a6 (/root/zephyr.exe+0x5312a6)
#4 0x52ed7b (/root/zephyr.exe+0x52ed7b)
#5 0x52eddd (/root/zephyr.exe+0x52eddd)
#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
==5==ABORTING
Signed-off-by: Sungwoo Kim <[email protected]>
1 task
1 task
JarmouniA
pushed a commit
to JarmouniA/zephyr_dev
that referenced
this pull request
Aug 8, 2025
1. Mostly complete. Supports MPU, userspace, PSPLIM-based stack guards, and FPU/DSP features. ARMv8-M secure mode "should" work but I don't know how to test it. 2. Designed with an eye to uncompromising/best-in-industry cooperative context switch performance. No PendSV exception nor hardware stacking/unstacking, just a traditional "musical chairs" switch. Context gets saved on process stacks only instead of split between there and the thread struct. No branches in the core integer switch code (and just one in the FPU bits that can't be avoided). 3. Minimal assembly use; arch_switch() itself is ALWAYS_INLINE, there is an assembly stub for exception exit, and that's it beyond one/two instruction inlines elsewhere. 4. Selectable at build time, interoperable with existing code. Just use the pre-existing CONFIG_USE_SWITCH=y flag to enable it. Or turn it off to evade regressions as this stabilizes. 5. Exception/interrupt returns in the common case need only a single C function to be called at the tail, and then return naturally. Effectively "all interrupts are direct now". This isn't a benefit currently because the existing stubs haven't been removed (see zephyrproject-rtos#4), but in the long term we can look at exploiting this. The boilerplate previously required is now (mostly) empty. 6. No support for ARMv6 (Cortex M0 et. al.) thumb code. The expanded instruction encodings in ARMv7 are a big (big) win, so the older cores really need a separate port to avoid impacting newer hardware. Thankfully there isn't that much code to port (see zephyrproject-rtos#3), so this should be doable. Signed-off-by: Andy Ross <[email protected]>
1 task
1 task
npitre
pushed a commit
to npitre/zephyr
that referenced
this pull request
Oct 10, 2025
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]>
npitre
pushed a commit
to npitre/zephyr
that referenced
this pull request
Oct 10, 2025
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]>
npitre
pushed a commit
to npitre/zephyr
that referenced
this pull request
Oct 11, 2025
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]>
npitre
pushed a commit
to npitre/zephyr
that referenced
this pull request
Oct 12, 2025
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]>
npitre
pushed a commit
to npitre/zephyr
that referenced
this pull request
Oct 13, 2025
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]>
npitre
pushed a commit
to npitre/zephyr
that referenced
this pull request
Oct 17, 2025
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]>
npitre
pushed a commit
to npitre/zephyr
that referenced
this pull request
Oct 17, 2025
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.
Signed-off-by: Nicolas Pitre <[email protected]>
npitre
pushed a commit
to npitre/zephyr
that referenced
this pull request
Oct 18, 2025
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.
Signed-off-by: Nicolas Pitre <[email protected]>
jhedberg
pushed a commit
that referenced
this pull request
Oct 21, 2025
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 #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.
Signed-off-by: Nicolas Pitre <[email protected]>
yuvraj-cirrent
pushed a commit
to yuvraj-cirrent/zephyr
that referenced
this pull request
Oct 21, 2025
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.
Signed-off-by: Nicolas Pitre <[email protected]>
billwatersiii
pushed a commit
to billwatersiii/zephyr
that referenced
this pull request
Oct 21, 2025
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.
Signed-off-by: Nicolas Pitre <[email protected]>
LingaoM
pushed a commit
to LingaoM/zephyr
that referenced
this pull request
Oct 23, 2025
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.
Signed-off-by: Nicolas Pitre <[email protected]>
hardevsinh-1
pushed a commit
to hardevsinh-1/zephyr
that referenced
this pull request
Oct 24, 2025
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.
Signed-off-by: Nicolas Pitre <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Just a test
Signed-off-by: Tyler Baker [email protected]