Feature #7907
closed
Add model for macro DECLARE_COMPLETION_ONSTACK (rule specification linux:kernel:sched:completion)
Added by Evgeny Novikov almost 8 years ago.
Updated almost 8 years ago.
Category:
Requirement specifications
Description
Likely there are many false alarms due to lack of this model on every version of the Linux kernel including 3.14. In addition corresponding test cases should be added (at least safe shouldn't be detected in case of absence of the model).
Related issues
1 (1 open — 0 closed)
including 3.14
Incorrect. In >3.12 macro DECLARE_COMPLETION_ONSTACK() is processed as INIT_COMPLETION(), whereas for more earlier kernels those macros are different.
For kernels ~2.6.33 fixed in branch fix_148_2.6.33.
I didn't noticed any changes in corresponding API. What differs and matters is a configuration. Before your fix there is just a model that works when CONFIG_LOCKDEP is true (which is usually the case for us). But when it is false, there isn't a model.
So first macro DECLARE_COMPLETION_ONSTACK should be modeled as you did. Second there should be a test case with an appropriate configuration that detects this issue.
Vitaly Mordan wrote:
Incorrect. In >3.12 macro DECLARE_COMPLETION_ONSTACK() is processed as INIT_COMPLETION()
My mistake, it is not connected to kernel version, but to its configuration.
With allmodconfig this issue cannot be revealed even in 2.6.33.
Confirmed, that in branch fix_148_2.6.33 all related false positive have gone.
There isn't still an appropriate test case that can reveal this issue. So I am going to add it myself.
There should be new job with another configuration for that test case.
Vitaly Mordan wrote:
There should be new job with another configuration for that test case.
Obviously, but you didn't add a corresponding sub-job.
- Status changed from New to Closed
I renamed the branch to fix-linux-kernel-sched-completion, add a required test case and test changes.
The most interesting thing was done within this issue is testing with using specific configuration files. This should be used within #7911.
Adding 2 sub-jobs for one module/rule leads to #7917. This should be fixed.
Also available in: Atom
PDF