linux-kernel - Re: Proposed changes to -rcu workflow

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-prev] [day] [month] [year] [list]

Message-Id: <20180625204349.GA25508@linux.vnet.ibm.com>
Date:   Mon, 25 Jun 2018 13:43:49 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     stern@...land.harvard.edu, andrea.parri@...rulasolutions.com,
        will.deacon@....com, peterz@...radead.org, boqun.feng@...il.com,
        npiggin@...il.com, dhowells@...hat.com, j.alglave@....ac.uk,
        luc.maranget@...ia.fr, akiyks@...il.com, josh@...htriplett.org,
        rostedt@...dmis.org, mathieu.desnoyers@...icios.com,
        jiangshanlai@...il.com, dave@...olabs.net
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Proposed changes to -rcu workflow

On Fri, Jun 22, 2018 at 02:26:15PM -0700, Paul E. McKenney wrote:
> Hello!
> 
> I am proposing changes to how I set up my -rcu tree:
> 
> 	The -rcu tree also takes LKMM patches, and I have been handling
> 	these completely separately, with one branch for RCU and another
> 	for LKMM. But this can be a bit inconvenient, and more important,
> 	can delay my response to patches to (say) LKMM if I am doing (say)
> 	extended in-tree RCU testing. So it is time to try something a
> 	bit different.
> 
> 	My current thought is continue to have separate LKMM and RCU
> 	branches (or more often, sets of branches) containing the commits
> 	to be offered up to the next merge window. The -rcu branch lkmm
> 	would flag the LKMM branch (or, more often, merge commit) and
> 	a new -rcu branch rcu would flag the RCU branch (or, again more
> 	often, merge commit). Then the lkmm and rcu merge commits would
> 	be merged, with new commits on top. These new commits would be
> 	intermixed RCU and LKMM commits.
> 
> 	The tip of the -rcu development effort (both LKMM and RCU)
> 	would be flagged with a new dev branch, with the old rcu/dev
> 	branch being retired. The rcu/next branch will continue to mark
> 	the commit to be pulled into the -next tree, and will point to
> 	the merge of the rcu and lkmm branches during the merge window.
> 
> 	I will create the next-merge-window branches sometime around
> 	-rc1 or -rc2, as I have in the past. I will send RFC patches to
> 	LKML shortly thereafter. I will send a pull request for the rcu
> 	branch around -rc5, and will send final patches from the lkmm
> 	branch at about that same time.
> 
> Thoughts?

Hearing no objections, I have rebased as described above.  The -rcu
branch "dev" now includes both LKMM and RCU changes.

							Thanx, Paul