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 paul...@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
Re: [PATCH tip/core/rcu 0/41] More RCU flavor consolidation cleanup for v4.21/v5.0
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 paul...@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 :)
--
Thanks,
Sasha
Re: [PATCH tip/core/rcu 0/41] More RCU flavor consolidation cleanup for v4.21/v5.0
On Mon, Nov 12, 2018 at 09:07:50AM -0500, Mathieu Desnoyers wrote:
> - On Nov 11, 2018, at 2:41 PM, paulmck paul...@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.
Thanx, Paul
Re: [PATCH tip/core/rcu 0/41] More RCU flavor consolidation cleanup for v4.21/v5.0
- On Nov 11, 2018, at 2:41 PM, paulmck paul...@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.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[PATCH tip/core/rcu 0/41] More RCU flavor consolidation cleanup for v4.21/v5.0
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.
Thanx, Paul
arch/powerpc/mm/hugetlbpage.c |
2
arch/s390/mm/pgalloc.c|
2
arch/sparc/oprofile/init.c|
2
crypto/pcrypt.c |
2
drivers/char/ipmi/ipmi_si_intf.c |
2
drivers/cpufreq/cpufreq_governor.c|
2
drivers/cpufreq/intel_pstate.c|
2
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |
6 +-
drivers/net/ethernet/realtek/8139too.c|
2
drivers/net/ethernet/realtek/r8169.c |
4 -
drivers/net/ethernet/sis/sis190.c |
2
drivers/vhost/net.c |
2
fs/file.c |
2
include/linux/percpu-rwsem.h |
2
include/linux/rcupdate_wait.h |
17 ---
include/linux/tracepoint.h|
2
include/linux/types.h |
4 -
init/main.c |
6 +-
kernel/cgroup/cgroup.c|
2
kernel/events/core.c |
2
kernel/kprobes.c |
10 ++--
kernel/livepatch/patch.c |
4 -
kernel/livepatch/transition.c |
4 -
kernel/locking/lockdep.c |
2
kernel/module.c |
14 ++---
kernel/rcu/sync.c |
12 ++---
kernel/rcu/tree.h |
15 --
kernel/rcu/update.c |
6 --
kernel/sched/core.c |
2
kernel/sched/cpufreq.c|
4 -
kernel/sched/cpufreq_schedutil.c |
2
kernel/sched/membarrier.c |
6 +-
kernel/trace/ftrace.c |
24 +-
kernel/trace/ring_buffer.c|
12 ++---
kernel/trace/trace.c |
10 ++--
kernel/trace/trace_events_filter.c|
4 -
kernel/trace/trace_kprobe.c |
2
kernel/tracepoint.c |
4 -
kernel/workqueue.c|
8 +--
lib/percpu-refcount.c |
2
mm/mmu_gather.c |
2
mm/slab.c |
4 -
mm/slab_common.c |
6 +-
net/bridge/br_mdb.c |
2
net/bridge/br_multicast.c |
14 ++---
net/core/netpoll.c|
4 -
net/core/skmsg.c |
2
net/decnet/af_decnet.c|
2
net/ipv4/netfilter/ipt_CLUSTERIP.c|
6 +-
net/netfilter/ipset/ip_set_hash_gen.h
