Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754426AbbFRJfl (ORCPT ); Thu, 18 Jun 2015 05:35:41 -0400 Received: from mga11.intel.com ([192.55.52.93]:50627 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752968AbbFRJff (ORCPT ); Thu, 18 Jun 2015 05:35:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,638,1427785200"; d="scan'208";a="745719834" From: Alexander Shishkin To: Ingo Molnar Cc: Peter Zijlstra , Vince Weaver , linux-kernel@vger.kernel.org, Ingo Molnar , Arnaldo Carvalho de Melo , Stephane Eranian , "Paul E. McKenney" Subject: Re: perf: aux area related crash and warnings In-Reply-To: <20150618090954.GB22009@gmail.com> References: <20150615122054.GY3644@twins.programming.kicks-ass.net> <87egld2l2o.fsf@ashishki-desk.ger.corp.intel.com> <87381rg9zx.fsf@ashishki-desk.ger.corp.intel.com> <20150618090954.GB22009@gmail.com> User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 18 Jun 2015 12:35:31 +0300 Message-ID: <87bngd2wbg.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1475 Lines: 46 Ingo Molnar writes: > * Alexander Shishkin wrote: > >> +void rb_free_aux(struct ring_buffer *rb) >> +{ >> + /* >> + * hold rb::refcount to make sure rb doesn't disappear >> + * before aux pages are freed >> + */ >> + if (WARN_ON_ONCE(!atomic_inc_not_zero(&rb->refcount))) >> + return; >> + >> + if (atomic_dec_and_test(&rb->aux_refcount)) >> + call_rcu(&rb->rcu_head, rb_free_rcu); >> + else >> + ring_buffer_put(rb); /* matches the increment above */ > > Is call_rcu() NMI-safe? I don't think so ... Actually, we couldn't establish that without Paul's help. > I think the life time rules of this object are really messed up if > they can be freed from any fast path. How come the freeing can happen > in NMI context? We ended up like this because we didn't want to stop the event once its AUX area gets unmapped, to be consistent with the behavior of normal perf events [1]. And somehow I completely missed the fact that this means freeing stuff in fast path. > Shouldn't the hardware first stop, then we can free things from the system call > path, or so? Yes, that's how we'll do it. [1] http://marc.info/?l=linux-kernel&m=141017607804348 Regards, -- Alex -- 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/