Mentees, please pick 1 or 2 projects and inform Shuah Khan. Please don't send email to mentors until introductions are made. Please include Shuah Khan on all your patch contributions.

Mentors, please send project summary to Shuah Khan. If you would like to get help with 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 Linux Kernel Mentorship Summer and Fall 2019 Project List for previous projects.

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: Brendan Higgins

Number of candidates selected for this project: 1

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: Neil Horman

Number of candidates selected for this project: 1

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:

• 8249c47c6ba4 ("fm10k: use generic PM hooks instead of legacy PCIe power hooks")
• 0e5d3da40055 ("i40e: use newer generic PM support instead of legacy PM callbacks")
• 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

Number of candidates selected for this project: 1

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

Number of candidates selected for this project: 1

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: Brendan Higgins

Number of candidates applying for this project: 0

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, Nicholas Mc Guire

Number of candidates applying for this project: 0

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

Number of candidates applying for this project: 0

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

Number of candidates applying for this project: 0

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 Fernandes

Number of candidates applying for this project: 2

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 Fernandes

Number of candidates applying for this project: 0

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: Sandhya Bankar

Number of candidates applying for this project: 0

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: Mauro Chehab

Number of candidates applying for this project: 0

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

Mentor: Mauro Chehab

Number of candidates applying for this project: 0

Update obsolete documentation files.

Mentor: Mauro Chehab

Number of candidates applying for this project: 0

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

Number of candidates applying for this project: 0

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

Number of candidates applying for this project: 0

__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

Number of candidates applying for this project: 0

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, __user, 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

Number of candidates working on this project: 1

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.

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 Harden list_for_each_entry_rcu() and family for details on the conversion that has been completed so far.

Sparse has shown many incorrect RCU pointer usage issues in the Linux kernel but it works only when RCU pointers are marked with __rcu. 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 __rcu annotations, but there are several more that need to be converted. 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.

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 Fernandes

Number of candidates working on this project: 3

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: Mauro Chehab

Number of candidates working on this project: 1