RCU git Tree

git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git

The following branches are of interest:

dev: Bleeding-edge code, both RCU and the Linux-kernel memory model. Please do any new RCU development against this branch.
rcu/next: Outside of the merge window, RCU commits that have passed a reasonable amount of testing, and have not yet been proven to be unready for the merge window. During the merge window, a commit merging the topic branches which have been accepted in -tip or which will be submitted directly to mainline during that merge window. If you want to look at or test newish RCU code, but nevertheless want something reasonably stable, this is your branch.
kcsan: Kernel concurrency sanitizer (KCSAN) updates intended or the next merge window. Prior to being added to this branch, KCSAN commits often spend some time in the dev branch.
lkmm: Linux-kernel memory model (LKMM) updates intended for the next merge window. Note that LKMM patches require at least one Acked-by: (or Reviewed-by:) from someone other than the author, and that Paul E. McKenney's Signed-off-by: does not count.
lkmm-dev: Linux-kernel memory model (LKMM) updates not deemed ready for the next merge window. Prior to being added to this branch, LKMM commits often spend some time in the dev branch.
urgent: Fixes for regressions in mainline.
main: The branch master will be a synonym for main until such time as it can be reasonably certain that users' git installations know about main. The presence of these two branches mean that someone cloning the -rcu tree will get a recent mainline RCU snapshot, perhaps excluding post-merge-window bug-fix patches. It is hoped that these branches will reduce the number of questions from beginners about ca. 2011 versions of RCU. (Unless they really do want to know about old versions of RCU, but experience indicates that such desires are not the common case.)

All of the above branches are subject to rebase. However, the old commits are kept around for at least six months by date-stamped branches, for example, “dev.2020.11.05a”.

This tree may be accessed as follows:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
cd linux-rcu
git checkout origin/dev

Once created, you can make your local copy incorporate changes as follows:

git remote update
git checkout origin/dev

If your development takes some time, please either rebase onto current origin/dev before sending your patches.

Regardless of how long your development takes, please test your code appropriately. The rcutorture test suite is easy to run on systems supporting KVM and qemu, so please give that a try, especially if your change is at all non-trivial. Of course, if you submit too many patches that breaks things, I am likely to insist that you run rcutorture on subsequent patches.

RCU Workflow

Shortly after -rc1, new commits that are deemed likely to be ready for the next merge window are collected into topic branches on top of -rc1. New commits that are not likely to be ready are rebased onto a merge of the topic branches. The dev branch includes these not-likely-to-be ready commits.
The commits in the topic branches are sent out for review. Feedback is applied by rebasing the relevant topic branches, updating commits, adding new commits, removing commits that prove unnecessary, or moving to the dev branch any commits that are shown to not be ready for mainline.
Should -rc1 prove insufficiently stable for RCU testing, these branches are rebased on top of a later -rc. In happy contrast with the situation prior to -next and kbuild test robot, -rc1 is usually sufficiently stable.
Once the branches have been created, new commits will normally be sent into the merge window following the next one. However, important bug fixes may be rebased onto one of the branches. Of course, trivial important bug fixes will be sent directly to mainline. The tradeoff is the urgency of the fix compared to the risk of bugs introduced by the fix itself.
Testing with later -rc releases from mainline is performed by first merging dev with that -rc, but leaving the dev branch unchanged. Such merges are sometimes referenced by a test branch, but these merges are often done within the confines of the test system.
Shortly after -rc6, the branches are frozen. If non-trivial important bug fixes arrive after -rc6, they will be pushed to mainline after the merge window closes. Trivial important bugs fixes might still be sent directly to mainline.
As you would expect, RCU commits move to mainline during the merge window.

RCU Current Tasks

Make RCU more friendly towards large deployments. This includes making rcutorture more user-friendly, enabling distributed rcutorture runs, and modifying RCU configuration and diagnostics as needed to be more compatible with such environments.
Add more forward-progress testing to rcutorture and fix any more bugs located thereby.
Come up with some way to warn about RCU callback overload conditions.