linux-kernel - Re: get_online_cpus() from a preemptible() context (bug?)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171106210718.GB3326@worktop>
Date:   Mon, 6 Nov 2017 22:07:18 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     James Morse <james.morse@....com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: get_online_cpus() from a  preemptible() context (bug?)

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 :-)