Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp380056yba; Wed, 15 May 2019 03:05:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqzJ5FCpB6WUOCSZ0Fg+5uE8jKywKmwhgyI91qQDxbOJkWbdhuwWN4k9PrKbh/kd4YhNvL8j X-Received: by 2002:aa7:8251:: with SMTP id e17mr26067809pfn.147.1557914758868; Wed, 15 May 2019 03:05:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557914758; cv=none; d=google.com; s=arc-20160816; b=ftOXflon9ATWNGgHNrBXhJqDIxaeOc7BVkjyDEbqF7n1N1/V9b2Cjdsdb65hnGxsH/ b33djFfxWcsqzbziPRL+KPk+hANcZvOXN7KHfXJmLw60ZaLMVR8eYEKVjmXDBdl5bIcu S6/jjb0RzUDRC/96WQf0e6CoAwKTxERB1WQ+VSmD2bQ6Us8Jmii3W3eQaLu91WCluUc0 qPKVda296iNQiEul2/vmGeywaSiTrbbS0UnuB0EM9S9PK2BVfUiElv58WcqiMig7ZPwE PExvUmxlX+t5h5NvermwkpGiE1q1u3+A8rGxFjgr+Zygk9pnefh8Bjx0Owjqr5Lc/xFr e+KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=mDeb10ZFTI7YY6v1jrh3xFq2p4nAG/+DwiS0ypMp8sA=; b=J9CrCR+uR+WbCJ760ANHooaI583JEVKgUgkhg6BBxp7dLpuGE9zUReOxDI9VO6o1qz azdZzsehs0bjLZXfA3oN3bJmsEJiD3LSxlBJhew35u9X9WNzX9RedxwiVk+u8dDvjNM5 l9NscePUX4/3+wVh8eN53/wqQkjYLkGq3WXloCZtAMYSTjXmPohsx3KcuwnAbDkZXw8l QGgzmEXhdJa2kgg6b2SAkbwmBxgR8U0Dn5ZlwAVPcCOtkx/h/yDoHS60lx3RdFkt9+DI DpAe55wC/NlamfYnNcGj/jUrMFby7IloybsRmKPNXnWf9HnG8Yv5cgN78sJwA2EJRgdL JBRQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c7si1827320pfp.40.2019.05.15.03.05.43; Wed, 15 May 2019 03:05:58 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726487AbfEOKEV (ORCPT + 99 others); Wed, 15 May 2019 06:04:21 -0400 Received: from mga14.intel.com ([192.55.52.115]:64924 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725966AbfEOKEU (ORCPT ); Wed, 15 May 2019 06:04:20 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 03:04:20 -0700 X-ExtLoop1: 1 Received: from um.fi.intel.com (HELO localhost) ([10.237.72.63]) by orsmga008.jf.intel.com with ESMTP; 15 May 2019 03:04:17 -0700 From: Alexander Shishkin To: Peter Zijlstra Cc: Yabin Cui , Ingo Molnar , Arnaldo Carvalho de Melo , Jiri Olsa , Namhyung Kim , linux-kernel@vger.kernel.org, alexander.shishkin@linux.intel.com Subject: Re: [PATCH] perf/ring_buffer: Fix exposing a temporarily decreased data_head. In-Reply-To: <20190515094352.GC2623@hirez.programming.kicks-ass.net> References: <20190515003059.23920-1-yabinc@google.com> <87ef50xlb8.fsf@ashishki-desk.ger.corp.intel.com> <20190515094352.GC2623@hirez.programming.kicks-ass.net> Date: Wed, 15 May 2019 13:04:16 +0300 Message-ID: <87bm04xcdb.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > On Wed, May 15, 2019 at 09:51:07AM +0300, Alexander Shishkin wrote: >> Yabin Cui writes: >> >> > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c >> > index 674b35383491..0b9aefe13b04 100644 >> > --- a/kernel/events/ring_buffer.c >> > +++ b/kernel/events/ring_buffer.c >> > @@ -54,8 +54,10 @@ static void perf_output_put_handle(struct perf_output_handle *handle) >> > * IRQ/NMI can happen here, which means we can miss a head update. >> > */ >> > >> > - if (!local_dec_and_test(&rb->nest)) >> > + if (local_read(&rb->nest) > 1) { >> > + local_dec(&rb->nest); >> >> What stops rb->nest changing between local_read() and local_dec()? > > Nothing, however it must remain the same :-) > > That is the cryptic way of saying that since these buffers are strictly > per-cpu, the only change can come from interrupts, and they must have a > net 0 change. Or rather, an equal amount of decrements to increments. > > So if it changes, it must also change back to where it was. Ah that's true. So the whole ->nest thing can be done with READ_ONCE()/WRITE_ONCE() instead? Because the use of local_dec_and_test() creates an impression that we rely on atomicity of it, which in actuality we don't. Regards, -- Alex