Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp6274554ybx; Mon, 11 Nov 2019 06:42:34 -0800 (PST) X-Google-Smtp-Source: APXvYqzL60kIbih/XhWSvSir5KwwCbgGah94x9tKaO8M0SZuHkma9cyXJfP4bPjHoh+TXLdd8YKA X-Received: by 2002:a17:906:1d59:: with SMTP id o25mr22558625ejh.17.1573483354206; Mon, 11 Nov 2019 06:42:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573483354; cv=none; d=google.com; s=arc-20160816; b=EDBxv7RnjCchw5CHVzzz0ca6SMt++l7jhnPLx1DZq8dMfdxWtW00gHlOe6IGjAlqKT 3GDJGM1t3JR28ITQUNTD6IbFeQSuUQVuk8XsA93ZgmMKGme0CwRLPNUY8+ktW6b6NGb6 4MnDkow8j2tKmN5iJPa0UcedlzPKWK1czhhDXvHPGdW3UGtmGBW2IWUSQSeS8bat9dI3 lKMLnFOjpwlcc+yq76Z1ywz8CJJxZUSd3RifeCHOm9l670AD2Dq3f7z6P2hrUQ0+/UmW 0rK6+276WHPHmCd+t8rkg9HPAEVBexoA0C00M/lIXdUnH3aSj1xzk/9XdkbhiG0nBFva eRHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=u9jAevKaMFAImoD+bnWzQZ+2970ceku97t7OTDsA8DA=; b=TI0kLTQih51/miVNeKq1wOgfaYe7RROdPSDDwksijTc1kdOMB/PqU/l4MsGutJYNGV 9o28WpjkG4MU1x6FNb9XAMQIyoXNLFf9tLOP6C1raNk8pFWOnDCJuUN8oBNDspJk+5+i ZNeg7PBctdjob3hxTWMP1arYGMDaoRlq4PaHlsat/0mI7yThg9oIGO/fbkhRaZ/ou5Tk oVU/y2yTyfqp65KRtgGzBeVNqeR1VSk0UZ+dIL3Kl1bt/4Wf70h8lVL54pVQIaYzNCYd mTYePe1kYtZbDRY7hFHT+HpnS3Tcj7UyoV6U4s4DLyhMfBMWBiH2jqVenRBAUtS91+Pa 2+6Q== 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 s7si12028027eds.215.2019.11.11.06.42.09; Mon, 11 Nov 2019 06:42:34 -0800 (PST) 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 S1727015AbfKKOjC (ORCPT + 99 others); Mon, 11 Nov 2019 09:39:02 -0500 Received: from mga07.intel.com ([134.134.136.100]:62624 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726903AbfKKOjC (ORCPT ); Mon, 11 Nov 2019 09:39:02 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Nov 2019 06:39:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,293,1569308400"; d="scan'208";a="213776866" Received: from linux.intel.com ([10.54.29.200]) by fmsmga001.fm.intel.com with ESMTP; 11 Nov 2019 06:39:00 -0800 Received: from [10.252.3.28] (unknown [10.252.3.28]) by linux.intel.com (Postfix) with ESMTP id BAFF35803A5; Mon, 11 Nov 2019 06:38:56 -0800 (PST) Subject: Re: [RFC] perf session: Fix compression processing To: Jiri Olsa , Arnaldo Carvalho de Melo Cc: Peter Zijlstra , Ingo Molnar , Alexander Shishkin , Namhyung Kim , Andi Kleen , linux-kernel References: <20191103222441.GE8251@krava> From: Alexey Budankov Organization: Intel Corp. Message-ID: Date: Mon, 11 Nov 2019 17:38:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191103222441.GE8251@krava> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04.11.2019 1:24, Jiri Olsa wrote: > hi, > --- > The compressed data processing occasionally fails with: > $ perf report --stdio -vv > decomp (B): 44519 to 163000 > decomp (B): 48119 to 174800 > decomp (B): 65527 to 131072 > fetch_mmaped_event: head=0x1ffe0 event->header_size=0x28, mmap_size=0x20000: fuzzed perf.data? > Error: > failed to process sample > ... > > It's caused by recent fuzzer fix that does not take into account > that compressed data do not need to by fully present in the buffer, > so it's ok to just return NULL and not to fail. > > Fixes: 57fc032ad643 ("perf session: Avoid infinite loop when seeing invalid header.size") > Link: http://lkml.kernel.org/n/tip-q1biqscs4stcmc9bs1iokfro@git.kernel.org > Signed-off-by: Jiri Olsa > --- > tools/perf/util/session.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c > index f07b8ecb91bc..3589ed14a629 100644 > --- a/tools/perf/util/session.c > +++ b/tools/perf/util/session.c > @@ -1959,7 +1959,7 @@ static int __perf_session__process_pipe_events(struct perf_session *session) > > static union perf_event * > fetch_mmaped_event(struct perf_session *session, > - u64 head, size_t mmap_size, char *buf) > + u64 head, size_t mmap_size, char *buf, bool decomp) bools in interface make code less transparent. > { > union perf_event *event; > > @@ -1979,6 +1979,8 @@ fetch_mmaped_event(struct perf_session *session, > /* We're not fetching the event so swap back again */ > if (session->header.needs_swap) > perf_event_header__bswap(&event->header); > + if (decomp) > + return NULL; > pr_debug("%s: head=%#" PRIx64 " event->header_size=%#x, mmap_size=%#zx: fuzzed perf.data?\n", > __func__, head, event->header.size, mmap_size); > return ERR_PTR(-EINVAL); > @@ -1997,7 +1999,7 @@ static int __perf_session__process_decomp_events(struct perf_session *session) > return 0; > > while (decomp->head < decomp->size && !session_done()) { > - union perf_event *event = fetch_mmaped_event(session, decomp->head, decomp->size, decomp->data); > + union perf_event *event = fetch_mmaped_event(session, decomp->head, decomp->size, decomp->data, true); It looks like this call can be skipped, at all, in this case. > > if (IS_ERR(event)) > return PTR_ERR(event); > @@ -2100,7 +2102,7 @@ reader__process_events(struct reader *rd, struct perf_session *session, > } > > more: > - event = fetch_mmaped_event(session, head, mmap_size, buf); > + event = fetch_mmaped_event(session, head, mmap_size, buf, false); > if (IS_ERR(event)) > return PTR_ERR(event); > > ~Alexey