linux-kernel - RCU branching for the v4.19 merge window

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 May 2018 07:40:44 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     rostedt@...dmis.org
Cc:     linux-kernel@...r.kernel.org
Subject: RCU branching for the v4.19 merge window

Hello, Steve!

Another year, another difficult-to-branch set of RCU commits.

In happy contrast to last year, I can make some branches (SRCU, some
of the torture commits, and a few miscellaneous commits), but I will
likely end up with several short branches and one huge one.  My thought
is to keep the long branch, but email the patches out in a few separate
serieses, with each depending on its predecessor.  For example, one series
from the big branch would be folding the ->gpnum and ->completed fields
into a single ->gp_seq, which helps the RCU-flavor consolidation task.
Another series suppresses some rare false-positive splats that have been
plaguing me for more than a year.  Yet another series within this huge
branch applies and optimizes funnel locking for grace-period startup.

The problem is that the conversion to ->gp_seq has a very large footprint,
which of course generates lots of conflicts.  I could of course collapse
these commits into a single commit, but if I did that I would also defer
to the merge window following v4.19 due to the resulting loss of bisection
within that change.

Any advice?

The commits are for-mingo..rcu/dev in my -rcu tree.

							Thanx, Paul