Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5633516ybe; Tue, 17 Sep 2019 11:02:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqzLsBL7hVMkWdmK8f5Wi7AcTLyN5lZX7pSdLdca9eDccp05VXsOeWYY/HbRRfEbSFAdvIw6 X-Received: by 2002:a50:ce53:: with SMTP id k19mr6022488edj.2.1568743322391; Tue, 17 Sep 2019 11:02:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568743322; cv=none; d=google.com; s=arc-20160816; b=DF9ThWuONIgdTXlHzB3ZWALZBBHU9v2nosLfVIompSkNzHECzTw4gjp5dTKoAUfFOG Vva0tVGLGNdm1DBgqgJiURmgEPQvtnUb+SjSDKAB6sYm4Y7iZYShMxXn7Hv9trixzmGX Xh03mVyxoTGhiVdjYMyPm7owZGgD3O3bqGDSCSKGbEWzNv6MoG4YWaJDCkTIxQy5glem zU5qt5ekfyDBG60M//RLt7jXTgdUAWro9bMxO+EKO81UeA03q47D+N+dDnmY70Mkkl4A fubrIzmIFF5jwabYnxPUumAJYrQT2grNzTzMmAGjYh4nD9NQw5tmoLM9nY+8U6u/o0N1 Z0vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=YcAbfXyz830sXTzIvB7W1vTWXcrJ69lwdIPLO/cVVK0=; b=SQG7+fwddQe2Cc6B8V780+haY6tXD6sM8Bpao+zQz4ZLN8bEB8QUfN+E92X6G6QEC2 vKzJfDq3GoAeBY5T6KqyOVdw4xIeHAM/jCzgc4MtgDXXKgF7H5fA3PEgk+CSzpak5U8D vRHZAXavFhUjpiS2x8j/FMZgbwMs3WqQ9cUMEIypv5eW7TlzfbDrr4Yt8mx+fqQcE5ok gBcrpIezk7uHo7O55uz1vafefpxAT4BtX6U0qQYXUIeqrGieeRz9GzjjNx+YFH6WjaSu 3QU/laOwt+abwcdjBcoMu7K9joF9FPJuWZ7XqIDWzTCvGtOE8o/bjlYE75noCM1B3Bx/ 4nDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1si1479702eji.86.2019.09.17.11.01.38; Tue, 17 Sep 2019 11:02:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727624AbfIQOnC (ORCPT + 99 others); Tue, 17 Sep 2019 10:43:02 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:42093 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725922AbfIQOnB (ORCPT ); Tue, 17 Sep 2019 10:43:01 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1iAEgu-0008Eh-MC; Tue, 17 Sep 2019 16:42:52 +0200 Date: Tue, 17 Sep 2019 16:42:52 +0200 From: Sebastian Andrzej Siewior To: Scott Wood Cc: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org, "Paul E . McKenney" , Joel Fernandes , Thomas Gleixner , Steven Rostedt , Peter Zijlstra , Juri Lelli , Clark Williams Subject: Re: [PATCH RT v3 1/5] rcu: Acquire RCU lock when disabling BHs Message-ID: <20190917144252.v34ina4z2ydchoit@linutronix.de> References: <20190911165729.11178-1-swood@redhat.com> <20190911165729.11178-2-swood@redhat.com> <20190917074456.yj7t3wdwuhn3zcng@linutronix.de> <63b430ca2f067e61bef1c387fad782ab4a2c1ed3.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <63b430ca2f067e61bef1c387fad782ab4a2c1ed3.camel@redhat.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-09-17 09:06:28 [-0500], Scott Wood wrote: > Sorry, I missed that you were asking about rcu_read_lock_bh() as well. I > did remove the change to rcu_read_lock_bh_held(). Sorry for not being clear here. > With this patch, local_bh_disable() calls rcu_read_lock() on RT which > handles this debug stuff. Doing it twice shouldn't be explicitly harmful, > but it's redundant, and debug kernels are slow enough as is. rcu_read_lock() does: | __rcu_read_lock(); | __acquire(RCU); | rcu_lock_acquire(&rcu_lock_map); | RCU_LOCKDEP_WARN(!rcu_is_watching(), | "rcu_read_lock() used illegally while idle"); __acquire() is removed removed by cpp. That RCU_LOCKDEP_WARN is doing the same thing as above and redundant. Am I right to assume that you consider rcu_lock_acquire(&rcu_bh_lock_map); redundant because the only user of that is also checking for rcu_lock_map? > -Scott Sebastian