From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751852AbdKFVH0 (ORCPT ); Mon, 6 Nov 2017 16:07:26 -0500 Received: from merlin.infradead.org ([205.233.59.134]:50058 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbdKFVHZ (ORCPT ); Mon, 6 Nov 2017 16:07:25 -0500 Date: Mon, 6 Nov 2017 22:07:18 +0100 From: Peter Zijlstra To: James Morse Cc: Thomas Gleixner , "linux-kernel@vger.kernel.org" Subject: Re: get_online_cpus() from a preemptible() context (bug?) Message-ID: <20171106210718.GB3326@worktop> References: <59FC8119.8030608@arm.com> <20171106103212.GG3165@worktop.lehotels.local> <5A00AF37.7030606@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A00AF37.7030606@arm.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 :-)