RCU git Tree


The following branches are of interest:

  1. dev: Bleeding-edge code, both RCU and the Linux-kernel memory model. Please do any new RCU development against this branch. Also, if you are wondering if I have pulled in your patch, this is the place to check. Please note that your patch might be quite a ways down the stack and might be in a branch whose merge commit feeds into the dev branch.
  2. 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 week prior to the merge window and during the merge window itself, this branch will reference a commit merging the various topic branches. If all goes well, all of these branches will be submitted 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.
  3. kcsan: Kernel concurrency sanitizer (KCSAN) updates intended for the next merge window. Prior to being added to this branch, KCSAN commits often spend some time in the dev branch.
  4. 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. Prior to being added to this branch, LKMM commits often spend some time in the dev branch.
  5. 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.
  6. nolibc: The nolibc library branch. Prior to being added to this branch, nolibc commits often spend some time in the dev branch.
  7. urgent: Fixes for regressions in mainline. In the hopefully rare cases where there are urgent fixes for more than one topic branch, an appropriate prefix or suffix will be used as needed.
  8. 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 pull recent changes into your local copy as follows:

git remote update
git checkout origin/dev

If your development takes some time, please 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 break things, I am likely to insist that you run rcutorture on subsequent patches.

In addition, please follow the advice in Documentation/process, including Documentation/process/submit-checklist.rst

RCU Workflow

Additional RCU Information

  1. RCU To-Do List
  2. Linux-Kernel RCU Design Documents
  3. Read-Copy Update (RCU) Papers
  4. A Tour Through rcutorture
  5. Stupid RCU Tricks
  6. Is Parallel Programming Hard, And If So, What Can You Do About It?