coccicheck
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
coccicheck [2016/06/22 00:04] Luis R. Rodriguez |
coccicheck [2018/01/17 14:05] Himanshu Jha [api] updated cocci rules |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ===== coccicheck ===== | ===== coccicheck ===== | ||
| - | '''coccicheck''' is one of the targets of the Linux kernel, this page documents how you can use it, what it provides and how to help extend it. '''coccicheck''' provides a series of semantic patches written in Semantic Patch Language (SmPL) and make use of the [[http://coccinelle.lip6.fr/|Coccinelle engine]] to interpret and complete these tests. These tests can help you vet for correctness and avoid certain bugs which have been able to be expressed semantically. | + | '''coccicheck''' is one of the targets of the Linux kernel, this page documents how you can use it, what it provides and how to help extend it. '''coccicheck''' provides a series of semantic patches written in Semantic Patch Language (SmPL) and makes use of the [[http://coccinelle.lip6.fr/|Coccinelle engine]] to interpret and complete these tests. These tests can help you vet for correctness and avoid certain bugs which have been able to be expressed semantically. |
| - | If you're a developer you are encouraged to vet for your patch using cocciecheck to ensure you are not introducing issues which are known semantically. If you're a maintainer you are encouraged to be using coccicheck with M=your/maintained-code-path so you can make use of the learned SmPL patches to avoid bugs in your maintained code. How maintainers can use this is explained below. Automatic code bot setups which test patches for inlusion upstream are encouraged to consider using 'make coccicheck' as well. | + | If you're a developer you are encouraged to vet your patch using cocciecheck to ensure you are not introducing issues which are known semantically. If you're a maintainer you are encouraged to be using coccicheck with M=your/maintained-code-path so you can make use of the SmPL patches to avoid known bugs in your maintained code. How maintainers can use this is explained below. Automatic code bot setups which test patches for inclusion upstream are encouraged to consider using 'make coccicheck' as well. |
| SmPL patches exist for a few different types of categories, documented below. | SmPL patches exist for a few different types of categories, documented below. | ||
| Line 11: | Line 11: | ||
| ==== Confidence ==== | ==== Confidence ==== | ||
| - | Eeach SmPL patch has a '''confidence''' tag associated with it, to help highlight how confident the devlelopers of the SmPL patch are that the reports / fixes generated by the SmPL patch will be accurate or relevant. If an SmPL patch has a '''High''' confidence annotated on it, it means that if you use coccicheck with it and it generates a report for a file there is a high degree of confidence that the report should be valid. Likewise if the confidence annotated is '''Low''' you should take good care to review the report/patch generated and vet for the validity of it before sending it to maintainers. | + | Eeach SmPL patch has a '''confidence''' tag associated with it, to help highlight how confident the devlelopers of the SmPL patch are that the reports / fixes generated by the SmPL patch will be accurate and/or relevant. If an SmPL patch has a '''High''' confidence annotated on it, it means that if you use coccicheck with it and it generates a report for a file there is a high degree of confidence that the report should be valid. Likewise if the confidence annotated is '''Low''' you should take good care to review the report/patch generated and vet the validity of it before sending it to maintainers. |
| ==== Modes ==== | ==== Modes ==== | ||
| Line 17: | Line 17: | ||
| There are four different modes you can use to use the semantic patches: | There are four different modes you can use to use the semantic patches: | ||
| - | * patch - lets you fix the issues found | + | * patch - lets you fix the issues found. |
| - | * report - lets you generate a report - this is the '''default''' mode if one is not specified | + | * report - lets you generate a report - this is the '''default''' mode if one is not specified. |
| - | * context - highlights lines of interest and their context in a diff-like style.Lines of interest are indicated with '-'. | + | * context - highlights lines of interest and their context in a diff-like style. Lines of interest are indicated with '-'. |
| - | * org - generates a report in the Org mode format of Emacs | + | * org - generates a report in the Org mode format of Emacs. |
| - | You specify the mode want to operate. Note that not all semantic patches implement all modes. For easy use | + | You specify the mode you want to operate. Note that not all semantic patches implement all modes. For easy use of Coccinelle, the default mode is "report". |
| - | of Coccinelle, the default mode is "report". | + | |
| Two other modes provide some common combinations of these modes. | Two other modes provide some common combinations of these modes. | ||
| Line 90: | Line 89: | ||
| </code> | </code> | ||
| - | In these modes, which works on a file basis, there is no information about semantic patches displayed, and no commit message proposed. | + | In these modes, which work on a file basis, there is no information about semantic patches displayed, and no commit message proposed. |
| This runs every semantic patch in scripts/coccinelle by default. The COCCI variable may additionally be used to only apply a single semantic patch as shown in the previous section. | This runs every semantic patch in scripts/coccinelle by default. The COCCI variable may additionally be used to only apply a single semantic patch as shown in the previous section. | ||
| Line 124: | Line 123: | ||
| Remove casting the values returned by memory allocation functions like kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc. This makes an effort to find cases of casting of values returned by kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc, kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes the casting as it is not required. The result in the patch case may need some reformatting. | Remove casting the values returned by memory allocation functions like kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc. This makes an effort to find cases of casting of values returned by kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc, kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes the casting as it is not required. The result in the patch case may need some reformatting. | ||
| - | === kzalloc-simple.cocci === | + | === zalloc-simple.cocci === |
| - | scripts/coccinelle/api/alloc/kzalloc-simple.cocci | + | scripts/coccinelle/api/alloc/zalloc-simple.cocci |
| - | Use kzalloc rather than kmalloc followed by memset with 0. This considers some simple cases that are common and easy to validate. Note in particular that there are no ...s in the rule, so all of the matched code has to be contiguous. | + | Use zeroing memory allocator function rather than allocator followed by memset with 0. This considers some simple cases that are common and easy to validate. Note in particular that there are no ...s in the rule, so all of the matched code has to be contiguous. |
| ==== free ==== | ==== free ==== | ||
| - | Avoid freeing bugs | + | Avoid freeing bugs. |
| ==== iterator ==== | ==== iterator ==== | ||
| - | Help vet for correctness when using kernel iterators | + | Help vet for correctness when using kernel iterators. |
| ==== locks ==== | ==== locks ==== | ||
| - | Vet for correct locking behaviour and avoid bugs | + | Vet for correct locking behaviour and avoid bugs. |
| ==== misc ==== | ==== misc ==== | ||
| Line 148: | Line 147: | ||
| ==== null ==== | ==== null ==== | ||
| - | Avoid null bugs | + | Avoid null bugs. |
| ==== tests ==== | ==== tests ==== | ||
| Line 156: | Line 155: | ||
| ===== Who runs these tests ===== | ===== Who runs these tests ===== | ||
| - | Linux kernel maintainers are encouraged to make use of the cocciecheck to vet for issues on their tree. This can be used to help review quality of patches before they get merged into your tree as well. | + | Linux kernel maintainers are encouraged to make use of the coccicheck to vet for issues on their tree. This can be used to help review quality of patches before they get merged into your tree as well. |
| - | These days coccicheck is run every now and then by Julia Lawall, false possitives are reviewed (in particular cocci files where confidence is annotated as low), and then once issues are confirmed patches typically are sent to maintainers. | + | These days coccicheck is run every now and then by Julia Lawall, false positives are reviewed (in particular cocci files where confidence is annotated as low), and then once issues are confirmed patches typically are sent to maintainers. |
| - | Average developers can and should use coccicheck as well but care should be taken to ensure the '''Confidence''' tag is reviewed and proper dilligence is done before sending any reports / fixes to kernel maintainers. | + | Average developers can and should use coccicheck as well but care should be taken to ensure the '''Confidence''' tag is reviewed and proper diligence is done before sending any reports / fixes to kernel maintainers. |
| It seems the zero day bot test infrastructure also makes use of 'make coccicheck' --- this section needs to be extended to document in what capacity this is done, how often, etc. | It seems the zero day bot test infrastructure also makes use of 'make coccicheck' --- this section needs to be extended to document in what capacity this is done, how often, etc. | ||
| Line 166: | Line 165: | ||
| ===== How often are these tests run ===== | ===== How often are these tests run ===== | ||
| - | The point of merging these SmPL patches upstream was to enable develoeprs and maintainers vet for code themselves. Ideally developers would run 'make coccicheck M=path/to-their-code/' prior to submitting a patch upstream, and maintainers would use it regularly, perhaps after applying new patches, to avoid introducing new issues. | + | The point of merging these SmPL patches upstream was to enable developers and maintainers to vet code themselves. Ideally developers would run 'make coccicheck M=path/to-their-code/' prior to submitting a patch upstream, and maintainers would use it regularly, perhaps after applying new patches, to avoid introducing new issues. |
| - | Time permitting Julia will also run these tests on her own when possible as linux-next moves on. There is no specific regular interval in which these tests are run. The zero day bot tests infrasctructure also seems to use 'make coccicheck' -- but this section should be extended to document this. | + | Time permitting Julia will also run these tests on her own when possible as linux-next moves on. There is no specific regular interval in which these tests are run. The zero day bot test infrastructure also seems to use 'make coccicheck' -- but this section should be extended to document this. |
coccicheck.txt · Last modified: 2018/01/17 14:05 by Himanshu Jha
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
