From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754239AbbFRJKI (ORCPT <rfc822;w@1wt.eu>);
	Thu, 18 Jun 2015 05:10:08 -0400
Received: from mail-wi0-f169.google.com ([209.85.212.169]:34327 "EHLO
	mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753230AbbFRJJ7 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 18 Jun 2015 05:09:59 -0400
Date: Thu, 18 Jun 2015 11:09:55 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Vince Weaver <vincent.weaver@maine.edu>, linux-kernel@vger.kernel.org,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Stephane Eranian <eranian@gmail.com>,
        "Paul E. McKenney" <paulmck@us.ibm.com>
Subject: Re: perf: aux area related crash and warnings
Message-ID: <20150618090954.GB22009@gmail.com>
References: <alpine.DEB.2.20.1506112305510.2757@vincent-weaver-1.umelst.maine.edu>
 <alpine.DEB.2.20.1506121431190.4444@vincent-weaver-1.umelst.maine.edu>
 <20150615122054.GY3644@twins.programming.kicks-ass.net>
 <87egld2l2o.fsf@ashishki-desk.ger.corp.intel.com>
 <87381rg9zx.fsf@ashishki-desk.ger.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87381rg9zx.fsf@ashishki-desk.ger.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Alexander Shishkin <alexander.shishkin@linux.intel.com> 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 ...

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? 
Shouldn't the hardware first stop, then we can free things from the system call 
path, or so?

Thanks,

	Ingo