Messages in this thread | | | Subject | Re: [patch 2/3] scheduler: add full memory barriers upon task switch at runqueue lock/unlock | From | Steven Rostedt <> | Date | Mon, 01 Feb 2010 11:24:37 -0500 |
| |
On Mon, 2010-02-01 at 11:09 -0500, Mathieu Desnoyers wrote:
> We can deal with the rq->cur update by holding the rq lock in each > iteration of the for_each_cpu(cpu, mm_cpumask(current->mm)) loop. This > ensures that if rq->cur is updated, we have an associated memory barrier > issued (e.g. on x86, implied by writing to cr3 while the rq lock is held). > > However, this does not deal with mm_cpumask update, and we cannot use > the per-cpu rq lock, as it's a process-wide data structure updated with > clear_bit/set_bit in switch_mm(). So at the very least, we would have to > add memory barriers in switch_mm() on some architectures to deal with > this. >
Doesn't set_bit imply a wmb()? If so couldn't we do:
What about:
again: tmp_mask = mm_cpumask(current->mm); smp_mb(); rcu_read_lock(); /* ensures validity of cpu_curr(cpu) tasks */ for_each_cpu(cpu, tmp_mask) { spin_lock_irq(&cpu_rq(cpu)->lock); ret = current->mm == cpu_curr(cpu)->mm; spin_unlock_irq(&cpu_rq(cpu)->lock); if (ret) smp_call_function_single(cpu, membarrier_ipi, NULL, 1); } rcu_read_unlock(); smp_mb(); if (tmp_mask != mm_cpumask(current->mm)) { /* do check for signals here */ goto again; }
Would the above work?
-- Steve
| |