From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752084AbdKFKcT (ORCPT ); Mon, 6 Nov 2017 05:32:19 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:52200 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750729AbdKFKcR (ORCPT ); Mon, 6 Nov 2017 05:32:17 -0500 Date: Mon, 6 Nov 2017 11:32:12 +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: <20171106103212.GG3165@worktop.lehotels.local> References: <59FC8119.8030608@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59FC8119.8030608@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 Fri, Nov 03, 2017 at 02:45:45PM +0000, James Morse wrote: > Hi Thomas, Peter, > > I'm trying to work out what stops a thread being pre-empted and migrated between > calling get_online_cpus() and put_online_cpus(). > > According to __percpu_down_read(), its the pre-empt count: > > * Due to having preemption disabled the decrement happens on > > * the same CPU as the increment, avoiding the > > * increment-on-one-CPU-and-decrement-on-another problem. > > > So this: > > void cpus_read_lock(void) > > { > > percpu_down_read(&cpu_hotplug_lock); > > + > > + /* Can we migrated before we release this per-cpu lock? */ > > + WARN_ON(preemptible()); > > } > > should never fire? It should.. You're reading a comment on __percpu_down_read() and using percpu_down_read(), _not_ the same function ;-) If you look at percpu_down_read(), you'll note it'll disable preemption before calling __percpu_down_read(). And yes, that whole percpu-rwsem code is fairly magical :-)