gsoc:2024-gsoc-lsb-projects
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
gsoc:2024-gsoc-lsb-projects [2024/01/12 19:09] till created |
gsoc:2024-gsoc-lsb-projects [2024/02/07 20:54] (current) khoroshilov |
||
|---|---|---|---|
| Line 11: | Line 11: | ||
| Code License: GPL/BSD, specs: GNU FDL | Code License: GPL/BSD, specs: GNU FDL | ||
| - | Mentors: Alexey Khoroshilov (alexey dot khoroshilov at gmail dot com), Jeff Licquia (licquia at linuxfoundation dot org), Vadim Mutilin, Denis Moskalev. | + | Mentors: Alexey Khoroshilov (alexey dot khoroshilov at gmail dot com), Jeff Licquia (licquia at linuxfoundation dot org), Vadim Mutilin, Denis Moskalev, Anton Vasilyev. |
| - | + | ||
| - | **Project ideas to be updated** | + | |
| - | + | ||
| - | =====Develop New Linux Test Suites===== | + | |
| - | + | ||
| - | 1-4 contributor full-size OR half-size | + | |
| - | + | ||
| - | LSB Desktop tests [1,2] is a part of LSB certification tests. Existing tests do not cover all interfaces included into LSB and LSB specification continues to grow ([[http://linuxbase.org/navigator/browse/status.php|http://linuxbase.org/navigator/browse/status.php]]). The goal of the project is to develop tests for newly included libraries and for interfaces that have no tests yet ([[http://linuxbase.org/navigator/coverage/cov2.php|http://linuxbase.org/navigator/coverage/cov2.php]]). | + | |
| - | + | ||
| - | Gtk3/Gdk3 and friends are at the moment very high on our list of untested items. The test development ideally should be coordinated with upstream projects so the tests can be useful for them as well. | + | |
| - | + | ||
| - | [1] [[http://bzr.linuxfoundation.org/loggerhead/lsb/devel/desktop-test/files|http://bzr.linuxfoundation.org/loggerhead/lsb/devel/desktop-test/files]]\\ [2] [[http://bzr.linuxfoundation.org/loggerhead/lsb/devel/t2c-desktop-tests/files|http://bzr.linuxfoundation.org/loggerhead/lsb/devel/t2c-desktop-tests/files]] | + | |
| - | + | ||
| - | **Desired knowledge:** C, Testing\\ Mentors: Alexey Khoroshilov, Roman Zybin | + | |
| =====Analysis and fixing of race condition warnings in the Linux kernel===== | =====Analysis and fixing of race condition warnings in the Linux kernel===== | ||
| - | 1 contributor full-size OR 2 contributors half-size | + | 1 contributor full-size OR 2 contributors half-size (350 hours), Level of difficulty: Hard |
| One of the most difficult to catch causes of bugs are race conditions — they may manifest itself only on rare schedules, and they are hard to fix — they usually require rethinking and careful selection of synchronization mechanism. Various methods exist for detecting race conditions. One of them is a static analysis, which allows to find errors in the module parts hardly reachable with testing. | One of the most difficult to catch causes of bugs are race conditions — they may manifest itself only on rare schedules, and they are hard to fix — they usually require rethinking and careful selection of synchronization mechanism. Various methods exist for detecting race conditions. One of them is a static analysis, which allows to find errors in the module parts hardly reachable with testing. | ||
| Line 41: | Line 27: | ||
| For each warning reported by LDV Tools a contributor should determine whether it is a bug or false warning. For that purpose a contributor should analyze each path for the feasibility in the Linux kernel. Moreover, a contributor should make sure the paths representing the threads may work in parallel in the Linux kernel and the assumptions about module environment are correct. | For each warning reported by LDV Tools a contributor should determine whether it is a bug or false warning. For that purpose a contributor should analyze each path for the feasibility in the Linux kernel. Moreover, a contributor should make sure the paths representing the threads may work in parallel in the Linux kernel and the assumptions about module environment are correct. | ||
| - | For accomplishing the task it is required to use the whole gamut of available means. A contributor should analyze kernel source code and documentation to determine the possibility of parallel execution of threads. For more precise analysis a contributor should use debugging tools and monitor thread creation inside the kernel subsystem for which the module is developed. It is required to use special tools modeling erroneous conditions, like [[https://forge.ispras.ru/projects/race-hound/wiki|RaceHound]] for reproducing the conditions along the path of the warning. | + | For accomplishing the task it is required to use the whole gamut of available means. A contributor should analyze kernel source code and documentation to determine the possibility of parallel execution of threads. For more precise analysis a contributor should use debugging tools and monitor thread creation inside the kernel subsystem for which the module is developed. It is required to use special tools modeling erroneous conditions, like [[https://www.kernel.org/doc/html/latest/dev-tools/kcsan.html|KCSan]] for reproducing the conditions along the path of the warning. |
| If a warning is classified as a bug then a contributor should prepare a patch fixing the bug and send it to the developers of the module. At the worst case, if by some reason it is impossible to prepare a patch a contributor should prepare and send a bug report. | If a warning is classified as a bug then a contributor should prepare a patch fixing the bug and send it to the developers of the module. At the worst case, if by some reason it is impossible to prepare a patch a contributor should prepare and send a bug report. | ||
| Line 47: | Line 33: | ||
| The false warnings should be classified. A contributor should determine if the warning is caused by inaccuracy of assumptions about the module environment, like the order of module callback invocations and the possibility to execute in parallel with each other, with interruptions, workqueue callbacks, etc. The warning may also be caused by inaccuracies in handling synchronization primitives, analysis of shared data, path conditions. | The false warnings should be classified. A contributor should determine if the warning is caused by inaccuracy of assumptions about the module environment, like the order of module callback invocations and the possibility to execute in parallel with each other, with interruptions, workqueue callbacks, etc. The warning may also be caused by inaccuracies in handling synchronization primitives, analysis of shared data, path conditions. | ||
| - | A contributor is expected to analyze and to classify about 500 warnings in a recent Linux kernel. | + | A contributor is expected to analyze and to classify about 200 warnings in a recent Linux kernel. |
| **Desired knowledge:** Linux kernel development, synchronization primitives, debugging tools for Linux kernel.\\ | **Desired knowledge:** Linux kernel development, synchronization primitives, debugging tools for Linux kernel.\\ | ||
| Line 54: | Line 40: | ||
| =====Development of environment model specifications for static verification of Linux Kernel===== | =====Development of environment model specifications for static verification of Linux Kernel===== | ||
| - | 1 contributor full-size | + | 1 contributor full-size (350 hours), Level of difficulty: Hard |
| The Linux Driver Verification (LDV) program aims to apply heavy-weight static verification tools to find bugs in Linux kernel modules. In contrast to widely used static analysis tools, the approach considers a module as a whole and performs thorough verification empowered by formal techniques. | The Linux Driver Verification (LDV) program aims to apply heavy-weight static verification tools to find bugs in Linux kernel modules. In contrast to widely used static analysis tools, the approach considers a module as a whole and performs thorough verification empowered by formal techniques. | ||
| Line 67: | Line 53: | ||
| **Desired knowledge:** C, understanding of Linux kernel including interrupt handling and deferred works execution.\\ | **Desired knowledge:** C, understanding of Linux kernel including interrupt handling and deferred works execution.\\ | ||
| - | **Mentors:** Eugene Novikov, Alexey Khoroshilov | + | **Mentors:** Anton Vasilyev, Alexey Khoroshilov |
gsoc/2024-gsoc-lsb-projects.1705086552.txt.gz · Last modified: 2024/01/12 19:09 by till
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
