Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753951AbbFPFpM (ORCPT ); Tue, 16 Jun 2015 01:45:12 -0400 Received: from mail-pd0-f172.google.com ([209.85.192.172]:34091 "EHLO mail-pd0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751392AbbFPFpH (ORCPT ); Tue, 16 Jun 2015 01:45:07 -0400 Message-ID: <557FB7E1.6080004@plumgrid.com> Date: Mon, 15 Jun 2015 22:45:05 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: paulmck@linux.vnet.ibm.com CC: Daniel Wagner , LKML Subject: Re: call_rcu from trace_preempt References: <557F509D.2000509@plumgrid.com> <20150615230702.GB3913@linux.vnet.ibm.com> <557F7764.5060707@plumgrid.com> <20150616021458.GE3913@linux.vnet.ibm.com> In-Reply-To: <20150616021458.GE3913@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2114 Lines: 56 On 6/15/15 7:14 PM, Paul E. McKenney wrote: > > Why do you believe that it is better to fix it within call_rcu()? found it: diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 8cf7304b2867..a3be09d482ae 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -935,9 +935,9 @@ bool notrace rcu_is_watching(void) { bool ret; - preempt_disable(); + preempt_disable_notrace(); ret = __rcu_is_watching(); - preempt_enable(); + preempt_enable_notrace(); return ret; } the rcu_is_watching() and __rcu_is_watching() are already marked notrace, so imo it's a good 'fix'. What was happening is that the above preempt_enable was triggering recursive call_rcu that was indeed messing 'rdp' that was prepared by __call_rcu and before __call_rcu_core could use that. btw, also noticed that local_irq_save done by note_gp_changes is partially redundant. In __call_rcu_core path the irqs are already disabled. > Perhaps you are self-deadlocking within __call_rcu_core(). If you have > not already done so, please try running with CONFIG_PROVE_LOCKING=y. yes, I had CONFIG_PROVE_LOCKING on. > I suspect that your problem may range quite a bit further than just > call_rcu(). For example, in your stack trace, you have a recursive > call to debug_object_activate(), which might not be such good thing. nope :) recursive debug_object_activate() is fine. with the above 'fix' the trace.patch is now passing. Why I'm digging into all of these? Well, to find out when it's safe to finally do call_rcu. If I will use deferred kfree approach in bpf maps, I need to know when it's safe to finally call_rcu and it's not an easy answer. kprobes potentially can be placed in any part of call_rcu stack, so things can go messy quickly. So it helps to understand the call_rcu logic well enough to come up with good solution. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/