Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Linux Kernel Mentorship Program Project List ======

Mentees, please pick 1 or 2 projects and inform **[[skhan@linuxfoundation.org|Shuah Khan]]**. **Please don't send email to mentors until introductions are made.** **Please include [[skhan@linuxfoundation.org|Shuah Khan]] on all your patch contributions.**

Mentors, please send project summary to [[skhan@linuxfoundation.org|Shuah Khan]]. If you would like to get help with [[https://syzkaller.appspot.com|syzbot bugs/issues]] in your area, please create a project around it. The goal is teaching bug analysis techniques and fix problems as needed.

Please refer to [[lkmp:lkmp_project_list_2019|Linux Kernel Mentorship Summer and Fall 2019 Project List]] for previous projects.

===== Summer 2020 Projects =====
===== Convert Runtime Tests to KUnit Tests =====
There are a number of runtime tests in the Linux kernel that are not KUnit tests and do not communicate their output in TAP (the Test Anything Protocol). Many of these tests are easy to run and at a high level follow most of the semantics of KUnit, but because they each use their own ad hoc mechanism to define test conditions the tests take more time to understand than if they were all defined using the same test framework. Additionally, because each one of these runtime tests use their own mechanism to report test output, common tools to parse and collect test results are difficult to write.

This project would entail converting over several of these runtime tests from an ad hoc mechanism to KUnit. Over the course of this process, some features missing from KUnit will likely become clear. Potential features that seem to be widely desired or particularly useful shall be documented, and if time allows, implemented.

**Mentor: [[brendanhiggins@google.com|Brendan Higgins]]**

**Number of candidates selected for this project: 1**

===== Dropwatch system enhancements =====
Dropwatch is a kernel feature that was implemented approximately 7 years ago. It makes use of kernel kprobes to monitor all locations in the kernel where network frames (specifically skb structures) are freed.  Using a kprobe, dropwatch records a histogram of the program counters where these skb free operations were preformed, and reports that information to a user space application which presents the information in a human readable form, allowing for fine grained monitoring of dropped packets with little to no latency, or ambiguity of cause.

Dropwatch consists of 3 primary components:
1) Kprobes, used to intercept calls to kfree_skb for the purpose of tracking
where packets are dropped

2) A Netlink protocol, used to allow user space to control the activation of
this feaure, and to receive the results of dropped packet reports

3) A user space application, used to drive the Netlink protocol

**Proposal**
I would like to propose that my mentee augment this kernel feature to create a dummy network interface, which exists for the purpose of cloning and queuing packets which otherwise would have been dropped by the kernel.  Adding this interface and queuing dropped packets to it, will allow for existing other userspace applications (like tcpdump or wireshark), to physically see and interpret those frames which would otherwise have been discarded by the kernel, so that developers can better understand why packets are being dropped, and potentially prevent the action in the future.

**Implementation details**
To accomplish this the mentee will need to:
a) Augment the kernel code to add netlink messages to control the creation and
teardown of an ethernet interface

b) Enhance the dropwatch kernel kprobes to enqueue dropped frames to the
interface in (a) when it exists

c) test the additional code to verify that it works.

**Mentor: [[nhorman@redhat.com|Neil Horman]]**

**Number of candidates selected for this project: 1**

===== PCI: Remove legacy power management =====
The current generic power management framework using ''struct dev_pm_ops''
was introduced over ten years ago.  The previous "legacy" framework
uses ''.suspend()'' and ''.resume()'' methods in the ''struct pci_driver''.  We
should convert all drivers from the legacy framework to the generic
framework and remove the legacy code from the PCI core.  Examples of
doing this include:

  * [[https://git.kernel.org/linus/8249c47c6ba4|8249c47c6ba4 ("fm10k: use generic PM hooks instead of legacy PCIe power hooks")]]
  * [[https://git.kernel.org/linus/0e5d3da40055|0e5d3da40055 ("i40e: use newer generic PM support instead of legacy PM callbacks")]]
  * [[https://git.kernel.org/linus/226e6b866d74|226e6b866d74 ("gpio: pch: Convert to dev_pm_ops")]]

The drivers can be converted one-by-one and the PCI core code removed
when it is no longer used.

**Mentor: [[bjorn@helgaas.com|Bjorn Helgaas]]**

**Number of candidates selected for this project: 1**

===== PCI: Hardening - Fix static analysis errors =====

Explore kernel static analysis checkers CocciCheck, Coverity, Sparse, and Smatch. Learn how to run them to find static analysis problems in the PCI sub-system and fix the reported errors.    

**Mentor: [[bjorn@helgaas.com|Bjorn Helgaas]]**

**Number of candidates selected for this project: 1**

===== Fall 2020 Projects - Apply from CommunityBridge =====

===== Add KUnit Support for Parameterized Testing =====
There are a number of KUnit tests for which a single logical test case is tested against a collection of parameters. For example, consider a test which tests a driver used to program a clock, such a driver might take a clock rate and would set divider registers based on some input clock. Many of the tests for such a driver would likely test that for some requested clock rate and some input rate, several registers would
get set to some set of values. We would likely want to do this for several sets of inputs and outputs, but otherwise the test logic is the same.

Currently, for a test which needs to test logic over a set of values, there are two options: either the test must have a loop inside of a test case which iterates over values - this has the downside that the resulting test failure reports are harder to understand than assertions with parameters that don't vary within iterations of a loop, or there must be one test case per each grouping of parameters to test - this has the downside that there is a bunch of duplicated logic.

Ideally, we would have something like what JUnit calls parameterized tests:

https://dzone.com/articles/junit-parameterized-test

Parameterized tests allow the test logic and the data passed into the test to be specified separately. Such a feature would have wide applicability in Linux kernel testing.

This project would entail designing a new API for defining parameterized tests, integrating parameterized tests into the KUnit reporting mechanism and converting some tests over to use this new API.

**Mentor: [[brendanhiggins@google.com|Brendan Higgins]]**

**Number of candidates applying for this project: 0**

===== Develop Methods for Tracking Tool Analysis Findings over Time =====
We use a number of tools, checkpatch.pl, coccinelle scripts, sparse, etc. and these tools report certain findings. While the valid ones are addressed by the kernel developers, the invalid tool findings are manually assessed and not acted upon. Over time with addressing the valid findings, the proportion of invalid findings increase compared to newly appearing valid findings, as invalid findings of those tools are not marked and tracked over the various versions.

In this project, the mentee should work out methods and tools to track the tool findings and make these tools useful in the Linux kernel community.

**Required Knowledge:**

  * Required: Very good knowledge of C, skill to READ AND UNDERSTAND source code in the Linux kernel in independent work
  * Required: Very good knowledge of python
  * Required: Good understanding of git
  * Recommended: Some understanding of static analysis tools
  * Recommended: Some understanding of coccinelle

**Mentor(s): [[lukas.bulwahn@gmail.com|Lukas Bulwahn]], [[der.herr@hofr.at|Nicholas Mc Guire]]**

**Number of candidates applying for this project: 0**

===== Patch Trace Analysis with PaStA =====
The PaStA tool, developed by Ralf Ramsauer, relates patch emails sent on the mailing lists to commits in the git repository. This allows to analyse the development process on the mailing list, measure some interesting metrics on the development, and identify outliers with respect to some central properties.

The issue tracker, https://github.com/lfd/PaStA/issues, provides a good overview of possible mentee activities in this project related to PaStA. A mentee start look into those issues and determine a suitable selection of tasks and goals from that issue tracker that can be handled within the timeframe of the Linux Kernel Mentorship project. A project proposal should breakdown the goals stated in the issue tracker to a more detailed plan of activities, needed extensions of PaStA and the implementation tasks.

**Mentor: [[ralf.ramsauer@oth-regensburg.de|Ralf Ramsauer]]**

**Number of candidates applying for this project: 0**

===== Add support for Latency Tolerance Reporting _DSM =====
Latency Tolerance Reporting is used to help manage ASPM (Active State
Power Management).  Some of the LTR values are platform-dependent and
must be learned from platform firmware.  Linux currently does not ask
firmware for this information.  I don't know exactly how this
information needs to be incorporated into the ASPM support, but I think
it's something we should figure out.  See the PCI Firmware Spec, r3.2,
sec 4.6.6.

**Mentor: [[bjorn@helgaas.com|Bjorn Helgaas]]**

**Number of candidates applying for this project: 0**


===== For a future session =====

===== Add PR_SET_VMA support to Linux Kernel =====
PR_SET_VMA mechanism is used heavily in Android for naming memory regions. It is passed to the prctl(2) system call along with the range of addresses to be named. The name appears in /proc/pid/maps and can be used to identify memory regions for debugging and accounting purposes. The patch has been carried in the Android tree for several years. The patch needs to be adapted to mainline, improved and finally upstreamed. This project will give the mentee a good understanding of virtual memory area structures in the Linux kernel as the name for the memory region is stored in these structures and there are various cases where a memory map needs to be split or merged depending on its name compared to its immediate neighbors.

**Mentor: [[joel@joelfernandes.org|Joel Fernandes]]**

**Number of candidates applying for this project: 2**

===== Linux kernel trace events in pstore =====
Pstore is a subsystem in the Linux kernel that is used to store kernel logs which can retrieved after a machine warm-reboots.

Currently, during ftrace tracing, ftrace events in the kernel are lost when a machine hard-locks up. There is a need for writing these events into the pstore so that after a lock up, the trace events that led to the crash can be retrieved from the Pstore after a warm reboot. This has to be done in a
scalable way so that tracing a live system does not impact performance of the system -- ftrace is extremely fast. Initial patches posted to write and retrieve events to/from pstore are not scalable due to locking and other issues. Introducing a scalable approach will open up more possibilities for crash analysis. Prototypes from Qualcomm (Sai Prakash) are available as a reference. These prototypes are not merge ready and suffer from scalablity issues but could be used as a starting point. Sai Prakash is presenting work done on the initial set of patches at Linaro Connect: https://linaroconnectsandiego.sched.com/event/Sue7/event-tracing-and-pstore-with-a-pinch-of-dynamic-debug
but further work or re-design of the approach is needed.

**Mentor: [[joel@joelfernandes.org|Joel Fernandes]]**

**Number of candidates applying for this project: 0**

===== Compile cross platforms drivers when COMPILE_TEST set =====
There are some drivers in Linux which get compiled on a limited set of platforms. Sometimes compilation of a driver is needed for compilation test coverage. In Linux we can check other platforms driver compilation by using COMPILE_TEST. This kind of driver may not load or work on the system but we can check its compilation.
On x86 platform there are lot of other platform drivers which are not getting compiled by default. We can make those drivers compile using COMPILE_TEST.

**Mentor: [[bankarsandhya512@gmail.com| Sandhya Bankar]]**

**Number of candidates applying for this project: 0**
===== Linux Media - Convert Videobuf v1 to Videobus v2 (9 projects) =====
Convert A requirement is that the developer has to have access to devices with use VB1 - either directly or we need to coordinate with someone with has the hardware for testing purposes. There are ~9 drivers that could be converted. Each driver is an independent project and will require 9 mentees.

**Mentor: [[mchehab@kernel.org| Mauro Chehab]]**

**Number of candidates applying for this project: 0**

===== Documentation - Convert (or add) kAPI/uAPI kerneldoc comments =====
Convert (or add) kAPI/uAPI kerneldoc comments, replacing or complementing existing .rst files

**Mentor: [[mchehab@kernel.org| Mauro Chehab]]**

**Number of candidates applying for this project: 0**

===== Documentation - Update obsolete .rst files =====
Update obsolete documentation files.

**Mentor: [[mchehab@kernel.org| Mauro Chehab]]**

**Number of candidates applying for this project: 0**

===== For a future session - PCI tasks (don't have the scope for being projects) =====
===== PCI: Align ''pcie_capability_read_word()'' error returns with other config read accessors =====
The ''pci_read_config_word()'' and similar interfaces set ''*val = ~0'' when
they fail, either because ''pci_dev_is_disconnected()'' or because a PCIe
hardware error is usually converted to ''~0'' data by the PCI host bridge.

But ''pcie_capability_read_word()'' sets ''*val = 0'' when
''pci_read_config_word()'' fails, so callers have to check for failure
differently than for ''pci_read_config_word()''.  These should be aligned
so all the config readers set ''*val = ~0'' to indicate "possible PCI
error response".

This will require changes to some callers of ''pci_read_config_word()''
that assume the read returns 0 on error.

**Mentor: [[bjorn@helgaas.com|Bjorn Helgaas]]**

**Number of candidates applying for this project: 0**

===== PCI: Audit ''pci_get_device()'' and ''for_each_pci_dev()'' uses for reference count issues =====
''pci_get_device()'' takes a reference on the ''pci_dev'' it returns.  The
caller is responsible for releasing the reference, either explicitly
with ''pci_dev_put()'' or by passing the ''pci_dev'' into another call of
''pci_get_device()''.

Sample problems in ''pasemi_dma_init()'':

  * If we find ''iob_pdev'' but not ''dma_pdev'', we leak the ''iob_pdev'' reference
  * Repeated ''pci_get_device(..., 0xa006)'' expression (more typical is a while loop as in ''alphabook1_init_pci()'')
  * Pointless ''pci_dev_put(pdev)'' when ''pdev'' is NULL after exiting the ''for()'' loops

and ''pas_setup_mce_regs()'':

  * if we exit the loop because ''reg >= MAX_MCE_REGS'', we leak the last reference

**Mentor: [[bjorn@helgaas.com|Bjorn Helgaas]]**

**Number of candidates applying for this project: 0**

===== PCI: Clean up HEST parsing =====
''%%__aer_firmware_first%%'' and ''%%__aer_firmware_first_valid%%'' are awkward.
Maybe the HEST parsing could be done in ''pci_acpi_setup()'' or somewhere
similar, ''%%__aer_firmware_first%%'' could be renamed and moved under the
''#ifdef CONFIG_PCIEAER'', and ''%%__aer_firmware_first_valid%%'' removed
completely.

**Mentor: [[bjorn@helgaas.com|Bjorn Helgaas]]**

**Number of candidates applying for this project: 0**


===== Spring 2020 Projects - completed =====
===== Linux dev-tools - Handling Complex Types and Attributes in Coccinelle =====
Coccinelle, developed by Julia Lawall and her group, is a program matching and transformation engine which provides the language SmPL (Semantic Patch Language) for specifying desired matches and transformations in C code. The project proposal would be to improve the management of complex types and attributes (const, <nowiki>__user</nowiki>, etc) in the program matching and transformation tool Coccinelle. Currently, complex types are represented incorrectly, which makes it impossible to match against them in a general way. Various kinds of attributes are increasingly used in Linux kernel code, and it is important to be able to check these annotations and add them where they are missing. This project is relevant to Linux, Zephyr and many more applications.

**Mentor: [[julia.lawall@lip6.fr|Julia Lawall]]**

**Number of candidates working on this project: 1**

===== RCU Hardening =====
This project has 3 parts as listed below, and all parts are part of the same project. All parts will be completed by the intern during the project.

==== 1. RCU Hardening - list_for_each_entry_rcu() hardening ====
A recent work has added basic support for RCU pointer-checking to list_for_each_entry_rcu() to avoid corruption of a list when the list is accessed without holding the rcu_read_lock(). rcu_dereference() has done this kind of pointer-checking all along. With support for list_for_each_entry_rcu() to do the same in upstream, drivers can now be converted to the API modifications for list_for_each_entry_rcu(). Once all drivers have been converted to use the new API, CONFIG_PROVE_RCU_LIST can be enabled by default without false-positives. Please refer to [[https://lore.kernel.org/patchwork/project/lkml/list/?series=402150|Harden list_for_each_entry_rcu() and family]] for details on the conversion that has been completed so far.

==== 2. RCU Hardening: RCU Sparse checking - convert RCU pointers to __rcu notation ====
Sparse has shown many incorrect RCU pointer usage issues in the Linux kernel but it works only when RCU pointers are marked with <nowiki>__rcu</nowiki>. It is quite important to do this marking, because with such marking, the RCU API does additional sparse checking. Many pointers in the Linux kernel have been converted to use <nowiki>__rcu</nowiki> annotations, but there are several more that need to be converted. [[https://patchwork.kernel.org/project/kernel-hardening/list/?series=94587|Conversions in scheduler]] are complete and can be used a a reference. The goal for this project is converting core kernel subsystems at first and then attempt to convert drivers.

==== 3. Sparse checking - Improve RCU Sparse checking ====
Sparse is a static analysis tool that has shown incorrect RCU usage issues. For example, if an RCU pointer is incorrectly dereferenced or assigned to something. However, the sparse tool is really noisy and shows false positives. This work item is to conduct a study of the usage of sparse tool on kernel code, specifically for RCU and to see if we can improve sparse or the code it is analyzing, make sparse less noisy for RCU (by removing false-positives) and prioritize the errors it is showing.

**Mentor: [[joel@joelfernandes.org|Joel Fernandes]]**

**Number of candidates working on this project: 3**



===== Linux Media - Virtual DVB test driver =====
Write a virtual DVB test front-end driver for ATSC, DVB C/S/S2 and ISDB-T. The goal for this Spring 2020 session is adding one front-end driver.

**Mentor: [[mchehab@kernel.org| Mauro Chehab]]**

**Number of candidates working on this project: 1**
Wiki

User Tools

Site Tools

Page Tools
