Re: linux-next: manual merge of the rcu tree with the tip tree
From: Peter Zijlstra <peterz@infradead.org>
Date: 2017-08-01 13:59:09
Also in:
lkml
On Tue, Aug 01, 2017 at 06:43:14AM -0700, Andy Lutomirski wrote:
Anyway, can you document whatever property you require with a comment in switch_mm() or wherever you're finding that property so that future arch changes don't break it?
We need _a_ smp_mb after rq->curr store. x86 has plenty.
quoted
+static void membarrier_private_expedited(void) +{ + int cpu; + bool fallback = false; + cpumask_var_t tmpmask; + + if (num_online_cpus() == 1) + return; + + /* + * Matches memory barriers around rq->curr modification in + * scheduler. + */ + smp_mb(); /* system call entry is not a mb. */ + + /* + * Expedited membarrier commands guarantee that they won't + * block, hence the GFP_NOWAIT allocation flag and fallback + * implementation. + */ + if (!zalloc_cpumask_var(&tmpmask, GFP_NOWAIT)) { + /* Fallback for OOM. */ + fallback = true; + } + + cpus_read_lock(); + for_each_online_cpu(cpu) { + struct task_struct *p; + + /* + * Skipping the current CPU is OK even through we can be + * migrated at any point. The current CPU, at the point + * where we read raw_smp_processor_id(), is ensured to + * be in program order with respect to the caller + * thread. Therefore, we can skip this CPU from the + * iteration. + */ + if (cpu == raw_smp_processor_id()) + continue; + rcu_read_lock(); + p = task_rcu_dereference(&cpu_rq(cpu)->curr); + if (p && p->mm == current->mm) {I'm a bit surprised you're iterating all CPUs instead of just CPUs in mm_cpumask().
Because ARM64 doesn't set any bits at all in there.