On Mon, Nov 06, 2017 at 06:51:35PM +0000, James Morse wrote:
> > If you look at percpu_down_read(), you'll note it'll disable preemption
> > before calling __percpu_down_read().
>
> Yes, this is how __percpu_down_read() protects the combination of it's
> fast/slow
> paths.
>
> But next percpu_down_read() calls preempt_enable(), I can't see what stops us
> migrating before percpu_up_read() preempt_disable()s to call __this_cpu_dec(),
> which now affects a different variable.
>
Ah, so the two operations that comment talks about are:
percpu_down_read_preempt_disable()
preempt_disable();
1) __this_cpu_inc(*sem->read_count);
if (unlikely(!rcu_sync_is_idle(&sem->rss)))
__percpu_down_read()
smp_mb()
if (likely(!smp_load_acquire(&sem->readers_block))) // false
__percpu_up_read()
smp_mb()
2) __this_cpu_dec(*sem->read_count);
rcuwait_wake_up(&sem->writer);
preempt_enable_no_resched();
If you want more detail on this, I'll actually have to go think :-)
