-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests: mem_protect: fix two issues #28102
tests: mem_protect: fix two issues #28102
Conversation
f5f25ac
to
196f74a
Compare
The implementations of the test cases had the wrong prototype. The extern declarations (which were in a C file for some reason) were correct. I don't want to talk about the subtle code generation and stack corruption issues that emerged from this which at one point made me question my own sanity. Signed-off-by: Andrew Boie <[email protected]>
We try to invoke `ztest_test_pass()` from inside a fatal exception in a child thread. On SMP this can result in the next test case starting on another CPU, re-using the child thread before it has a chance to exit. Signed-off-by: Andrew Boie <[email protected]>
196f74a
to
9c6db39
Compare
@andrewboie This is labeled as bug. Is there an issue # we could link to? |
@jenmwms there is not, I root caused this when working on #26486 and #27533 If a bug were opened, I wouldn't have anything further to add than what is already in the PR description / patch commit messages |
no problem, just thought I should ask. Great eye to catch bugs early :) |
This fixes two very subtle problems with the mem_protect test.
The first is that this tests was calling
ztest_test_pass()
out of a fatal exception handler for a child thread. On an SMP system, this could cause the next test case to immediately start on another CPU before the child thread self-exits. If the next test tried to recycle the child thread object, the kernel goes haywire. Fixes a very rare crash on x86_64 (and other SMP systems). This could simply be removed since the ztest thread is joining on the child threads anyway.The second fixes a problem where the implementations of the test functions had the wrong prototype. The extern prototypes in another C file (?? why not a header?) were correct (otherwise the setup of the test suite would have caught it) and we had a mismatch. This on x86 fooled the compiler into thinking the stack frame was laid out in a way that wasn't true if it tried to chain execution with
jmp
to the last function in the test case instead of calling it and then issuingret
, since x86 marshals arguments on the stack and not registers.Debugging the latter issue was the engineering equivalent of slowly going insane staring at assembly code and stack contents, wondering if the compiler was bugged