Document limitations of net_buf queuing functions #28355
Comments
|
I vaguely remember some discussion around moving to use a separate fragments list net_buf struct member rather than reusing the first four bytes of the net_buf struct (combined with flags) for this purpose. This would remove this limitation in the implementation. @carlescufi was it with you that this came up? |
It might've been because I also have a vague recollection of this. I am not up to speed with the problem right now, but feel free to include me in a discussion about this after the release. |
Document limitations on the FIFO queuing functions when fragments are used. Namely that the `get` functions are not thread-safe when fragments are present. This is due to multiple independent calls to `k_fifo_get/sys_slist_get`. A second thread can interrupt the retrieval before all fragments have been removed. The second thread can then read from the FIFO, obtaining the trailing fragments as a 'new' `net_buf`. The first thread will then either assert or pull in the next `net_buf` on the queue as part of the first `net_buf`. Fixes #28355 Signed-off-by: Jordan Yates <[email protected]>
Document limitations on the FIFO queuing functions when fragments are used. Namely that the `get` functions are not thread-safe when fragments are present. This is due to multiple independent calls to `k_fifo_get/sys_slist_get`. A second thread can interrupt the retrieval before all fragments have been removed. The second thread can then read from the FIFO, obtaining the trailing fragments as a 'new' `net_buf`. The first thread will then either assert or pull in the next `net_buf` on the queue as part of the first `net_buf`. Fixes zephyrproject-rtos#28355 Signed-off-by: Jordan Yates <[email protected]>
Is your enhancement proposal related to a problem? Please describe.
The current documentation for
net_buf_getandnet_buf_slist_getdoes not specify that the functions are only safe to use from a single thread if the net_buf contains fragments.Describe the solution you'd like
Documentation that describes the above, or an alternate implementation that does not suffer the same problems.
Additional context
The functions are not thread safe due to multiple independent calls to
k_fifo_get, which can be interrupted at any point in time.The
net_buf_putvariants are fine as they use an atomic functionk_fifo_put_list.The text was updated successfully, but these errors were encountered: