kernel: fix runtime initialization of k_pipe object #24526
Conversation
Runtime initialization failed to reset the lock field, causing problems when the pipe object is located on a stack and passed by reference to other code. Lacking an API for initializing a spinlock by itself use the idiom from _K_PIPE_INITIALIZER(). To simplify maintainability the initialization order is changed slightly to match the structure field declaration order. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
There was a problem hiding this comment.
Where's the spot where there's a struct k_pipe on the stack? Is it in-tree? I'm trying to track spots like this down where synchronized objects are located in stack memory.
On cache-incoherent architectures, there's a desire that we place all the synchronized data in an uncached region. User stacks would be cached by default, but that breaks paradigms like this.
|
@andyross I'm unaware of in-tree uses. There is a use in the test provided by #24486, where I encountered it during review posted in the original issue; also the author of that PR asked about the fault on slack which reminded me of the failure and its solution (in that situation, use the existing statically allocated pipe). I'm not in favor of allocating pipes on a stack, but in restricted situations it might work and be useful, so it seems worthwhile avoiding an uninitialized-memory-reference if it happens. |
|
This fixes some issues I've observed. E.g. if a k_pipe is k_malloc'ed or if it's on the stack as well. |
Runtime initialization failed to reset the lock field, causing
problems when the pipe object is located on a stack and passed by
reference to other code. Lacking an API for initializing a spinlock
by itself use the idiom from _K_PIPE_INITIALIZER().
To simplify maintainability the initialization order is changed
slightly to match the structure field declaration order.
Signed-off-by: Peter Bigot peter.bigot@nordicsemi.no