Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp356827ybr; Fri, 22 May 2020 08:15:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwgzHHgMyvU3Ql8iZNQbgL9h83LyTvfVcwxi0cjgKAF9H3OM4q2TsnGzA6q+eFPVolLsIRp X-Received: by 2002:a17:907:4031:: with SMTP id nk1mr8437183ejb.51.1590160505720; Fri, 22 May 2020 08:15:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590160505; cv=none; d=google.com; s=arc-20160816; b=ajVDaFMoeOpNihrkw6sMNJNPEaAQXQ/QMMTbAdHehRkcJZADAZf6PBO7U/t9DTP0BJ oEe95uSQA98x2Gw39LAqnTlCbXWAcuch80y7xEIlhUHKdqi8pNb4PgQoys7NF2oaNN9+ M7pxpHIFPVFgMCT7vfqH+si+wso3Fd2RAKPIBJimNxPHJr1uGcE2krihBIlwh904O/Iu +mKePgQ4wKDsoiUH0ryhAWSoXpHbbnDFFBvE0aLxPj07FbNTfQ0xZUgCAQ95GvxgnP3Q gSx2Vp75g+bphwIqCczSSuhd3ZxMxFRKe4yjE6JZjeEwz3Z9eUmS9w9Yggzg6KKwaBLD 2AgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=tynBaC0BHCwrID7Ofd8PVfHv7Ab7mMmHT9anAXz30S0=; b=pylq7tO+gOF4QoORr5dDEqqFGMMPX399LGdUB1lec3iMKADR6MD5gzq4mBxSXg3QR1 63ULnzq4bLnaSfDutbGLgCRyi611DL23rbtrGrsfeE5NSz/gyuTQAbcH7nKlq60y1Je+ 9Vf/qFPlOKjGjW7tK1bmilzVyXqs60TG4CoQhy7X9l4UU+pceF1M2qzK8YEtBURw2yax vdG3ULMuNTTvL704OVv9VZla5Zcxx+mLwttOlhOnel37UNW5ODqsmuy49LuXNLVRCu2c kLc6Bn3JxDwHfGkhPcweP/ScqnKBELZLtOl4jxPipIesD1vBlx84m0rdHfu2QayPjzNm 5TUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sa8si5183609ejb.222.2020.05.22.08.14.42; Fri, 22 May 2020 08:15:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730312AbgEVPNO (ORCPT + 99 others); Fri, 22 May 2020 11:13:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729929AbgEVPNN (ORCPT ); Fri, 22 May 2020 11:13:13 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 658BAC061A0E; Fri, 22 May 2020 08:13:13 -0700 (PDT) Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1jc9Lz-0007Ty-9D; Fri, 22 May 2020 17:12:55 +0200 Date: Fri, 22 May 2020 17:12:55 +0200 From: Sebastian Andrzej Siewior To: "Paul E. McKenney" Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Ingo Molnar , Steven Rostedt , Will Deacon , Thomas Gleixner , Linus Torvalds , Lai Jiangshan , Josh Triplett , Mathieu Desnoyers , rcu@vger.kernel.org Subject: Re: [PATCH 3/8] srcu: Use local_lock() for per-CPU struct srcu_data access Message-ID: <20200522151255.rtqnuk2cl3dpruou@linutronix.de> References: <20200519201912.1564477-1-bigeasy@linutronix.de> <20200519201912.1564477-4-bigeasy@linutronix.de> <20200520102407.GF317569@hirez.programming.kicks-ass.net> <20200520120608.mwros5jurmidxxfv@linutronix.de> <20200520184345.GU2869@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200520184345.GU2869@paulmck-ThinkPad-P72> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-05-20 11:43:45 [-0700], Paul E. McKenney wrote: > > Yes, that CPU's rcu_segcblist structure does need mutual exclusion in > this case. This is because rcu_segcblist_pend_cbs() looks not just > at the ->tails[] pointer, but also at the pointer referenced by the > ->tails[] pointer. This last pointer is in an rcu_head structure, and > not just any rcu_head structure, but one that is ready to be invoked. > So this callback could vanish into the freelist (or worse) at any time. > But callback invocation runs on the CPU that enqueued the callbacks > (as long as that CPU remains online, anyway), so disabling interrupts > suffices in mainline. > > Now, we could have srcu_might_be_idle() instead acquire the sdp->lock > to protect the structure. Joel suggested that. > What would be really nice is a primitive that acquires such a per-CPU > lock and remains executing on that CPU, whether by the graces of > preempt_disable(), local_irq_save(), migrate_disable(), or what have you. It depends on what is required. migrate_disable() would limit you to executing one CPU but would allow preemption. You would need a lock to ensure exclusive access to the data structure. preempt_disable() / local_irq_save() guarantee more than that. Looking at the two call-sites there is no damage there is a CPU migration after obtaining the per-CPU pointer. There could be a CPU-migration before and after the pointer has been obtained so the code before and after this function can not make any assumptions. Would something like this work: ? diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c --- a/kernel/rcu/srcutree.c +++ b/kernel/rcu/srcutree.c @@ -764,14 +764,15 @@ static bool srcu_might_be_idle(struct srcu_struct *ssp) unsigned long t; unsigned long tlast; + check_init_srcu_struct(ssp); /* If the local srcu_data structure has callbacks, not idle. */ - local_irq_save(flags); - sdp = this_cpu_ptr(ssp->sda); + sdp = raw_cpu_ptr(ssp->sda); + spin_lock_irqsave_rcu_node(sdp, flags); if (rcu_segcblist_pend_cbs(&sdp->srcu_cblist)) { - local_irq_restore(flags); + spin_unlock_irqrestore_rcu_node(sdp, flags); return false; /* Callbacks already present, so not idle. */ } - local_irq_restore(flags); + spin_unlock_irqrestore_rcu_node(sdp, flags); /* * No local callbacks, so probabalistically probe global state. @@ -851,9 +852,8 @@ static void __call_srcu(struct srcu_struct *ssp, struct rcu_head *rhp, } rhp->func = func; idx = srcu_read_lock(ssp); - local_irq_save(flags); - sdp = this_cpu_ptr(ssp->sda); - spin_lock_rcu_node(sdp); + sdp = raw_cpu_ptr(ssp->sda); + spin_lock_irqsave_rcu_node(sdp, flags); rcu_segcblist_enqueue(&sdp->srcu_cblist, rhp); rcu_segcblist_advance(&sdp->srcu_cblist, rcu_seq_current(&ssp->srcu_gp_seq)); That check_init_srcu_struct() is needed, because otherwise: | BUG: spinlock bad magic on CPU#2, swapper/0/1 | lock: 0xffff88803ed28ac0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 | CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc6+ #81 | Call Trace: | dump_stack+0x71/0xa0 | do_raw_spin_lock+0x6c/0xb0 | _raw_spin_lock_irqsave+0x33/0x40 | synchronize_srcu+0x24/0xc9 | wakeup_source_remove+0x4d/0x70 | wakeup_source_unregister.part.0+0x9/0x40 | device_wakeup_enable+0x99/0xc0 I'm not sure if there should be an explicit init of `wakeup_srcu' or if an srcu function (like call_srcu()) is supposed to do it. > Thanx, Paul Sebastian