Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp5115568img; Wed, 27 Mar 2019 02:20:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqy5Ln356IVFDm/FQVSWvRvTc9QMoQfO/bm7EgE7fIgQhgkIyOKgecJX10RS9F2bi+KWhU5t X-Received: by 2002:a17:902:9341:: with SMTP id g1mr36140657plp.80.1553678413482; Wed, 27 Mar 2019 02:20:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553678413; cv=none; d=google.com; s=arc-20160816; b=HXvYrGPiLGBGra9QCWyp2EIvC04470CXHo3GA5+DAXxIVOs2l870AyG8qSUdirixKs PCQrjZKA6cmMaW9eVKJobMzrwk8PMEGDy63YazSsrvltjyXzm53telmMkEO6Wf6muluN VwXeMtsISfJKgIy/quIJNtM/ePuTD7dJYz+zwNb4bUvtSufq8vKAh24/hJYN6zOHQ/G4 0krXLRZNsahnJkJ0wu5tC6cJkwkq+jmn0RKVySiqCNivxJ+xH2JikoNPpsD2y1/Emmz5 g6Vv4NaE5C1L0DYlehcx+ITvnO9pfMOsMqiGJFs8DRlrUsY/BLQtcPbTDEZX0K1907Pb awrg== 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=CRKNi80V6cRjQC53CWWreEZ+ZWySqsMlphvWi6vjFqE=; b=ORQlOSr3+pD2Gk5bwr/GjecasWDdL7vgDn6H2aW7W8vkE0GUUFHq/+ge+CXMmBR/wj Gdc/tKlMgLmZdBd6AnJnNjjp78pxCe8ew1+SYh/DLZFWOGDdBxVlIpucRKjhuCoL7Bhf bus/Mf/zjeeFHT+v1i6cM+kWlynWqJyrml1Xd0TT3vR+xRwlRfB1BvjBHJQr9j9c1UoE hDyRxDIMpcp/Vg3q3zxcMZYEqBTxoCiDZ5Pqp8tCXCXLKzE6ISMXJtsjC3T9eZfp9KdI svS7YLzIX4ZvSaSU1bKIslyGq05pvR9HS8Z7cXaxsxbUxRWS20Yd/oSbEXLOdG+JK+4M zGBw== 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 u18si8340765pgk.469.2019.03.27.02.19.57; Wed, 27 Mar 2019 02:20:13 -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 S1732499AbfC0JRt (ORCPT + 99 others); Wed, 27 Mar 2019 05:17:49 -0400 Received: from mga14.intel.com ([192.55.52.115]:29121 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726257AbfC0JRs (ORCPT ); Wed, 27 Mar 2019 05:17:48 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2019 02:17:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,276,1549958400"; d="scan'208";a="331086745" Received: from um.fi.intel.com (HELO localhost) ([10.237.72.178]) by fmsmga006.fm.intel.com with ESMTP; 27 Mar 2019 02:17:44 -0700 From: Alexander Shishkin To: Ben Gainey , "mingo\@kernel.org" , "peterz\@infradead.org" , "acme\@redhat.com" , Will Deacon Cc: "linux-arm-kernel\@lists.infradead.org" , "linux-kernel\@vger.kernel.org" , alexander.shishkin@linux.intel.com Subject: Re: BUG in "perf: Suppress AUX/OVERWRITE records"? In-Reply-To: <3f04004a48a4b5bece9d277d5c51661f4eca7e97.camel@arm.com> References: <87k1gm86en.fsf@ashishki-desk.ger.corp.intel.com> <3f04004a48a4b5bece9d277d5c51661f4eca7e97.camel@arm.com> Date: Wed, 27 Mar 2019 11:17:43 +0200 Message-ID: <87wokk7k20.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 Ben Gainey writes: >> It was an unintentional side effect that it also >> happened to coincide with context switches in the overwrite mode. > > I'm not using overwrite mode, I'm opening the mmap with PROT_WRITE > (i.e. in truncate mode). Now I get it. Does the below fix the problem for you? From bf52320cce0e74a2c0d987db7bd571f7687b4f4f Mon Sep 17 00:00:00 2001 From: Alexander Shishkin Date: Wed, 27 Mar 2019 11:05:53 +0200 Subject: [PATCH] perf: Fix AUX record suppression Commit 1627314fb54a33e ("perf: Suppress AUX/OVERWRITE records") has an unintended side-effect of also suppressing all AUX records with no flags and non-zero size, so all the regular records in the full trace mode. This breaks some use cases for people. Fix this by restoring "regular" AUX records to their former glory. Signed-off-by: Alexander Shishkin Fixes: 1627314fb54a33e ("perf: Suppress AUX/OVERWRITE records") Reported-by: Ben Gainey CC: stable@vger.kernel.org # v4.20+ --- kernel/events/ring_buffer.c | 33 +++++++++++++++------------------ 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c index 678ccec60d8f..626256dc26c1 100644 --- a/kernel/events/ring_buffer.c +++ b/kernel/events/ring_buffer.c @@ -455,24 +455,21 @@ void perf_aux_output_end(struct perf_output_handle *handle, unsigned long size) rb->aux_head += size; } - if (size || handle->aux_flags) { - /* - * Only send RECORD_AUX if we have something useful to communicate - * - * Note: the OVERWRITE records by themselves are not considered - * useful, as they don't communicate any *new* information, - * aside from the short-lived offset, that becomes history at - * the next event sched-in and therefore isn't useful. - * The userspace that needs to copy out AUX data in overwrite - * mode should know to use user_page::aux_head for the actual - * offset. So, from now on we don't output AUX records that - * have *only* OVERWRITE flag set. - */ - - if (handle->aux_flags & ~(u64)PERF_AUX_FLAG_OVERWRITE) - perf_event_aux_event(handle->event, aux_head, size, - handle->aux_flags); - } + /* + * Only send RECORD_AUX if we have something useful to communicate + * + * Note: the OVERWRITE records by themselves are not considered + * useful, as they don't communicate any *new* information, + * aside from the short-lived offset, that becomes history at + * the next event sched-in and therefore isn't useful. + * The userspace that needs to copy out AUX data in overwrite + * mode should know to use user_page::aux_head for the actual + * offset. So, from now on we don't output AUX records that + * have *only* OVERWRITE flag set. + */ + if (size || (handle->aux_flags & ~(u64)PERF_AUX_FLAG_OVERWRITE)) + perf_event_aux_event(handle->event, aux_head, size, + handle->aux_flags); rb->user_page->aux_head = rb->aux_head; if (rb_need_aux_wakeup(rb)) -- 2.20.1