Messages in this thread | | | Date | Mon, 12 Nov 2018 14:16:35 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH tip/core/rcu 0/41] More RCU flavor consolidation cleanup for v4.21/v5.0 |
| |
On Mon, Nov 12, 2018 at 04:40:23PM -0500, Sasha Levin wrote: > On Mon, Nov 12, 2018 at 08:01:37AM -0800, Paul E. McKenney wrote: > >On Mon, Nov 12, 2018 at 09:07:50AM -0500, Mathieu Desnoyers wrote: > >>----- On Nov 11, 2018, at 2:41 PM, paulmck paulmck@linux.ibm.com wrote: > >> > >>> Hello! > >>> > >>> This series does additional cleanup for the RCU flavor consolidation, > >>> focusing primarily on uses of old API members, for example, so that > >>> call_rcu_bh() becomes call_rcu(). There are also a few straggling > >>> internal-to-RCU cleanups. > >>> > >>> 1. Remove unused rcu_state externs, courtesy of Joel Fernandes. > >>> > >>> 2. Fix rcu_{node,data} comments about gp_seq_needed, courtesy of > >>> Joel Fernandes. > >>> > >>> 3. Eliminate synchronize_rcu_mult() and its sole caller. > >>> > >>> 4. Consolidate the RCU update functions invoked by sync.c. > >>> > >>> 5-41. Replace old flavorful RCU API calls with the corresponding > >>> vanilla calls. > >> > >>Hi Paul, > >> > >>Just a heads up: we might want to spell out warnings in very big letters > >>for anyone trying to backport code using RCU from post-4.21 kernels > >>back to older kernels. I fear that newer code will build just fine > >>on older kernels, but will spectacularly fail in hard-to-debug ways at > >>runtime. > >> > >>Renaming synchronize_rcu() and call_rcu() to something that did not > >>exist in prior kernels would prevent that. It may not be as pretty > >>though. > > > >From v4.20 rather than v4.21, but yes. Would it make sense to have Sasha > >automatically flag -stable candidates going back past that boundary that > >contain call_rcu(), synchronize_rcu(), etc.? Adding Sasha on CC, and > >I might be able to touch base with him this week. > > We had a similar issue recently with a vfs change > (https://patchwork.kernel.org/patch/10604339/) leading to potentially > the same results as described above, we took it as is to avoid these > issues in the future, though this is a much smaller change than what's > proposed here. > > We can look into an good way to solve this. While I can alert on > post-4.20 stable tagged patches that touch rcu, do you really want to be > dealing with this for the next 10+ years? It'll also means each of those > patches will need a manual backport. > > Let's talk at Plumbers :)
Sounds like a plan! ;-)
Thanx, Paul
| |