Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4210022ybi; Mon, 29 Jul 2019 21:39:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqwXBEV2gj3F7HX229BLV/LVxRaacw+rUsGK1YpcvIWX/ImHc6IlpJA1T7RMGOPmbsWbyD/G X-Received: by 2002:a63:4612:: with SMTP id t18mr98611271pga.85.1564461545809; Mon, 29 Jul 2019 21:39:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564461545; cv=none; d=google.com; s=arc-20160816; b=X5YJxvrlvT9yKtKWZyVM5Mywv+p/GgvcwUWd5vuW9jjBLXuDPwmMazU/oCrNsDESTi /8CVdeXgTp0omO/hLKRh35SVfI4c2c8XxVDoodaAR2ZjKqDpwe3dt0KhJX5R76EggJgs BYTln7j0DmlvVSmpb6PkMKIKKQ6JkABLrZytNdT7Kz6AQNwOH2TQwOlbcKHGsura9T1y DQ6aoFMq90KcmjsJNqo2DBClDj0sNgEQitnD01cxkpP+9ZZ/NPmZMy50SpwAa/PQPUei Q7QAhBopkW7a3XBL67tIDjwDgGCdZ18x7Sc7B57BalWJVfwq9SIvFRULpHeM4GuKsxnw QGMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=F5mdKNo5jpQJp7dsTcNEtucoWZvy1PUc4OMjvK3GGOQ=; b=MPWIHgc0YAmTco/IGFo9bUOVS+zIEkJuH78nhrabapwTp9rg2McZ+jhla90q7+qTvp +ymBrT6Wtm1VCMxFqp/6AfaZdQPj/eNb5IsZD1qVLmifuPZ/9mfY9L803hNNUUe2OgID 6aUhooM9+VmWG7IOgwScsZw+r/0ZxvAlFzp9EY334K864py8pgQd7qIhUDCSYvRPDhGM 066JNbZZm271+XK+4xtIY20VCeNbOsvA983AypE5Y6Sw0YmrQYLJsCZjVgoOWR9oXPpX uG0uvqXN+zEDQ5aShh92+UBUj1SEyelbchyUY1Cw1yGVM4BOYXPUC7G3x1EqcSSPfAhK S5iA== 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 31si26259445pld.245.2019.07.29.21.38.50; Mon, 29 Jul 2019 21:39:05 -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 S1730719AbfG3B7r (ORCPT + 99 others); Mon, 29 Jul 2019 21:59:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:37076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725864AbfG3B7r (ORCPT ); Mon, 29 Jul 2019 21:59:47 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5C65E206E0; Tue, 30 Jul 2019 01:59:45 +0000 (UTC) Date: Mon, 29 Jul 2019 21:59:43 -0400 From: Steven Rostedt To: Eiichi Tsukata Cc: Peter Zijlstra , Andy Lutomirski , Joel Fernandes , "Paul E. McKenney" , Thomas Gleixner , Ingo Molnar , Frederic Weisbecker , LKML Subject: Re: [PATCH] tracing: Prevent RCU EQS breakage in preemptirq events Message-ID: <20190729215943.63ff2081@oasis.local.home> In-Reply-To: References: <20190729010734.3352-1-devel@etsukata.com> <20190729102948.GY31381@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 30 Jul 2019 10:50:36 +0900 Eiichi Tsukata wrote: > > > > I think they already (try to) do that; see 'tracing_irq_cpu'. > > > > Or you mean something like this? > As for trace_hardirqs_off_caller: You missed what Peter said. > > diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c > index 4d8e99fdbbbe..d39478bcf0f2 100644 > --- a/kernel/trace/trace_preemptirq.c > +++ b/kernel/trace/trace_preemptirq.c > @@ -66,7 +66,7 @@ __visible void trace_hardirqs_off_caller(unsigned long caller_addr) > if (!this_cpu_read(tracing_irq_cpu)) { ^^^^^^^^^^^^^^^ The above makes this called only the first time we disable interrupts. > this_cpu_write(tracing_irq_cpu, 1); > tracer_hardirqs_off(CALLER_ADDR0, caller_addr); > - if (!in_nmi()) > + if (!in_nmi() && !irqs_disabled()) This would always be false. This function is always called with irqs_disabled()! So no, this is not what is meant. > trace_irq_disable_rcuidle(CALLER_ADDR0, caller_addr); > } > > Or > > diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c > index 4d8e99fdbbbe..e08c5c6ff2b3 100644 > --- a/kernel/trace/trace_preemptirq.c > +++ b/kernel/trace/trace_preemptirq.c > @@ -66,8 +66,6 @@ __visible void trace_hardirqs_off_caller(unsigned long caller_addr) > if (!this_cpu_read(tracing_irq_cpu)) { > this_cpu_write(tracing_irq_cpu, 1); > tracer_hardirqs_off(CALLER_ADDR0, caller_addr); > - if (!in_nmi()) > - trace_irq_disable_rcuidle(CALLER_ADDR0, caller_addr); And this just removes the tracepoint completely? -- Steve > } > > > As for trace_hardirqs_on_caller, it is called when IRQs off and CONTEXT_USER. > So even though we skipped the trace event if the previous state was already IRQs on, > we will fall into the same situation.