Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1709661imm; Thu, 12 Jul 2018 06:38:50 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdMhI7BHqeMzrz2+v6CM5KMZDPDZEuFrOQyM1MHC6A1RDL31k07zAAXJPi2ukjmir1gEtFD X-Received: by 2002:a63:2359:: with SMTP id u25-v6mr2208430pgm.220.1531402730106; Thu, 12 Jul 2018 06:38:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531402730; cv=none; d=google.com; s=arc-20160816; b=Hltj0Ry+AuXk4yBMsi6iryDnREpBrso2mcCwzIb62BS2kosB87zmUJe+4hNCzdtbtU kR8Q4QAxYez909WihOZdr5hTSuCp/D/wOZ0k54c1n/bZvHcgMfsTc31PJ4n7nr0ng48h lb0TQgHK/ov8UOyg9n7NrfsL586BeNDAJFoM/kV1YeU5BVVWTYDxHRk6kc5yyqfpmwB+ DUXUzU+EAe/3svRYNt32UEmYdJ6V832glAy0uL3LeWeC4H2HN1m/2zM9tmJ7C3gzVhR3 ZpsRMngy4xpTXQzXTSQJ82Goy66Cw9q9ZCwoM83/JTOuxwVpOmsHObGr6EL14um7VCW2 b0Ug== 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 :arc-authentication-results; bh=sfUWb59QmdgE8kB0j1n68GirB7nAVDCA4fIgDrjCra4=; b=NgJb9Ch1vpEN7xm6177fcdYeUXWGRhPxT/Dg+Q/0H5tT9Ckq4RxkCxQxpbvuJs8f5v hPiBqhEHSO1MM2RgVivZ1QoYsz3xWNzZQXSWjWexWlBPZdyO9bK78MBPzL8eC/cFiluH DhmcQBpMO7IA+vpp5IxZuGNmuS3AcNNvTX5P0tpulPJAUhYwayzrdjHCI1eSVS4yj96X hSpSMdxhiWzIlXY/vnhPJ/L1jBDMx8LIAX5u4nPV5cMYgkd4+GjZKJrsU9S/qNk+GVGi QLrGk+fKxNaAnCfQGI7F+BzDN1QWtbl5j02Aw8K9s3LiFiyoG/aIQZpp60K5C6XbBou6 S+lw== 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 123-v6si12508777pfd.201.2018.07.12.06.38.27; Thu, 12 Jul 2018 06:38:50 -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 S1732403AbeGLNr2 (ORCPT + 99 others); Thu, 12 Jul 2018 09:47:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:48178 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726812AbeGLNr1 (ORCPT ); Thu, 12 Jul 2018 09:47:27 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (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 4187E21479; Thu, 12 Jul 2018 13:37:49 +0000 (UTC) Date: Thu, 12 Jul 2018 09:37:47 -0400 From: Steven Rostedt To: Joel Fernandes Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Boqun Feng , Byungchul Park , Ingo Molnar , Julia Cartwright , linux-kselftest@vger.kernel.org, Masami Hiramatsu , Mathieu Desnoyers , Namhyung Kim , Paul McKenney , Thomas Glexiner , Tom Zanussi , kernel-team@android.com Subject: Re: [PATCH v9 5/7] tracing: Centralize preemptirq tracepoints and unify their usage Message-ID: <20180712093747.4fca1642@gandalf.local.home> In-Reply-To: <20180712083805.GA67912@joelaf.mtv.corp.google.com> References: <20180628182149.226164-1-joel@joelfernandes.org> <20180628182149.226164-6-joel@joelfernandes.org> <20180711131256.GH2476@hirez.programming.kicks-ass.net> <20180711091944.4d8e78ef@gandalf.local.home> <20180712083805.GA67912@joelaf.mtv.corp.google.com> X-Mailer: Claws Mail 3.16.0 (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 Thu, 12 Jul 2018 01:38:05 -0700 Joel Fernandes wrote: > So actually with or without the clean up, I don't see any issues with > dropping lockdep_recursing in my tests at the moment. I'm not sure something > else changed between then and now causing the issue to go away. I can include > Peter's clean up in my series though if he's Ok with it since you guys agree > its a good clean up anyway. Would you prefer I did that, and then also > dropped the lockdep_recursing checks? Or should I keep the > lockdep_recursing() checks just to be safe? Do you see cases where you want > irqsoff tracing while lockdep_recursing() is true? I say rewrite it as per Peter's suggestion. Perhaps even add credit to Peter like: Cleaned-up-code-by: Peter Zijlstra ;-) And yes, I would recommend dropping the lockdep_recursion() if you can't trigger issues from within your tests. If it shows up later, we can always add it back. Thanks! -- Steve