Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp772670ybk; Wed, 20 May 2020 11:33:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5new7OTz9dYXnxZvwC/8fjG5EVH1tVjItPDqXiDehREFOWMJysrLZGg1RoOVCawvgdXBY X-Received: by 2002:a17:906:7146:: with SMTP id z6mr367478ejj.315.1589999612627; Wed, 20 May 2020 11:33:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589999612; cv=none; d=google.com; s=arc-20160816; b=x9Obf2lW96gAa/6e3LXz0AePmsTrhw19hoL5xHOtQqgU5JmM4Anpg1klFacW0R5js2 LQXjfF9xB+Qh6LV2zaz9aG9dhk1v5bAjKRhon9VHF0kfqRQLwe0Kla3VjJZ5JLRdTqCd +E809pdfHJCZcv2LG+rAkQK6w06xZmsyr/zzd/NtflfhdKfZnkn4AAernaOZR9m9mo0S kvkJoZNgCUYtt9J/bAjHGvxxHUsW0Q9F4oX7IBy/NhTtOH90NQrB4m6hx5/G/9pnWlbP caAfODCYI9junQexB3iXZi5JCr0Aa93/PmdnwFpXWjUd2WY8RlhIVWdz0ZdddJdlLYee Xzkw== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=m8bqDA/pym5oEuz+XRMMiTvhK8OsswvsffDbXpW+jMc=; b=nJO0zmOdfqzABC9IWyCY0Lk7TczGAQtwR7aaQkTfHgC49sfeK4kn0R9SKpMzmHJ4/F 6l/PuXtZ0yaNqnSWXGHrS9e3NK/7LmBBKLfuJaoEIF20sZ/JNOt7ihKg1KkCmdPZIft3 0XU1T6FH9YMppXXl7yCPWI+t2psWc52+i8s3q5ig1Bhua8Jixxa1cF3gyyUPZcqyyd8M /s6dx+Imluvi6JS0/YJ5ikHVh0aCQVxD/n5OHKJ/FzKee8ArrbN5h5dvgws3aJZ9Ny7x WJJpS1PStMmQVzLngyY3wz1LeVy5i410TJKZfCx2QZFWiSLfOq/ZbA7WaVa6Q8OUKCK9 KQuQ== 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 a16si2096590ejs.58.2020.05.20.11.33.09; Wed, 20 May 2020 11:33:32 -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 S1727004AbgETS2j convert rfc822-to-8bit (ORCPT + 99 others); Wed, 20 May 2020 14:28:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726729AbgETS2h (ORCPT ); Wed, 20 May 2020 14:28:37 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BE59C061A0E; Wed, 20 May 2020 11:28:37 -0700 (PDT) Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1jbTRg-0008Qk-Ns; Wed, 20 May 2020 20:28:00 +0200 Date: Wed, 20 May 2020 20:28:00 +0200 From: Sebastian Andrzej Siewior To: Joel Fernandes Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Ingo Molnar , Steven Rostedt , Will Deacon , Thomas Gleixner , "Paul E . McKenney" , 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: <20200520182800.sdp6t6bgbhn4kkqk@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> <20200520174259.GA247557@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20200520174259.GA247557@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-05-20 13:42:59 [-0400], Joel Fernandes wrote: > Hi Sebastian, Hi Joel, > For pointer stability, can we just use get_local_ptr() and put_local_ptr() > instead of adding an extra lock? This keeps the pointer stable while keeping > the section preemptible on -rt. And we already have a lock in rcu_data, I > prefer not to add another lock if possible. What is this get_local_ptr() doing? I can't find it anywhere… > I wrote a diff below with get_local_ptr() (just build tested). Does this > solve your issue? see below. > > I remember Paul looked at that patch a few years ago and he said that > > that disabling interrupts here is important and matches the other part > > instance where the interrupts are disabled. Looking at it now, it seems > > that there is just pointer stability but I can't tell if > > rcu_segcblist_pend_cbs() needs more than just this. > > Which 'other part' are you referring to? Your patch removed local_irq_save() > from other places as well right? The patch converted hunks. > thanks, > > - Joel > > ---8<----------------------- > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c > index 8ff71e5d0fe8b..5f49919205317 100644 > --- a/kernel/rcu/srcutree.c > +++ b/kernel/rcu/srcutree.c > @@ -778,13 +778,17 @@ static bool srcu_might_be_idle(struct srcu_struct *ssp) > unsigned long tlast; > > /* If the local srcu_data structure has callbacks, not idle. */ > - local_irq_save(flags); > - sdp = this_cpu_ptr(ssp->sda); > + sdp = get_local_ptr(ssp->sda); > + spin_lock_irqsave_rcu_node(sdp, flags); You acquire the node lock which was not acquired before. Is that okay? How is get_local_ptr() different to raw_cpu_ptr()? > if (rcu_segcblist_pend_cbs(&sdp->srcu_cblist)) { > - local_irq_restore(flags); > + spin_unlock_irqrestore_rcu_node(sdp, flags); > + put_local_ptr(sdp); > return false; /* Callbacks already present, so not idle. */ > } > - local_irq_restore(flags); > + > + spin_unlock_irqrestore_rcu_node(sdp, flags); > + put_local_ptr(sdp); > > /* > * No local callbacks, so probabalistically probe global state. Sebastian