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;
Date:   Mon, 4 Nov 2019 09:40:24 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc:     Arnaldo Carvalho de Melo <acme@redhat.com>,
        Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org,
        jolsa@redhat.com, adrian.hunter@intel.com,
        mathieu.poirier@linaro.org, mark.rutland@arm.com
Subject: Re: [PATCH v3 1/3] perf: Allow using AUX data in perf samples
Message-ID: <20191104084024.GZ4131@hirez.programming.kicks-ass.net>
References: <20191025140835.53665-1-alexander.shishkin@linux.intel.com>
 <20191025140835.53665-2-alexander.shishkin@linux.intel.com>
 <20191028162712.GH4097@hirez.programming.kicks-ass.net>
 <87tv7sg5ml.fsf@ashishki-desk.ger.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87tv7sg5ml.fsf@ashishki-desk.ger.corp.intel.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Oct 28, 2019 at 07:08:18PM +0200, Alexander Shishkin wrote:

> > @@ -6318,11 +6318,12 @@ static void perf_aux_sample_output(struc
> >  
> >  	/*
> >  	 * Guard against NMI hits inside the critical section;
> > -	 * see also perf_aux_sample_size().
> > +	 * see also perf_prepare_sample_aux().
> >  	 */
> >  	WRITE_ONCE(rb->aux_in_sampling, 1);
> > +	barrier();
> 
> Isn't WRITE_ONCE() barrier enough on its own? My thinking was that we
> only need a compiler barrier here, hence the WRITE_ONCE.

WRITE_ONCE() is a volatile store and (IIRC) the compiler ensures order
against other volatile things, but not in general.

barrier() OTOH clobbers all of memory and thereby ensures nothing can
get hoised over it.

Now, the only thing we do inside this region is an indirect call, which
on its own already implies a sync point for as long as the compiler
cannot inline it, so it might be a bit paranoid on my end (I don't think
even LTO can reduce this indirection and cause inlining).