From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933862AbbI2Imn (ORCPT ); Tue, 29 Sep 2015 04:42:43 -0400 Received: from terminus.zytor.com ([198.137.202.10]:37729 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933805AbbI2Im1 (ORCPT ); Tue, 29 Sep 2015 04:42:27 -0400 Date: Tue, 29 Sep 2015 01:42:12 -0700 From: tip-bot for Adrian Hunter Message-ID: Cc: jolsa@redhat.com, mingo@kernel.org, adrian.hunter@intel.com, tglx@linutronix.de, hpa@zytor.com, linux-kernel@vger.kernel.org, acme@redhat.com Reply-To: linux-kernel@vger.kernel.org, hpa@zytor.com, tglx@linutronix.de, acme@redhat.com, jolsa@redhat.com, adrian.hunter@intel.com, mingo@kernel.org In-Reply-To: <1443186956-18718-4-git-send-email-adrian.hunter@intel.com> References: <1443186956-18718-4-git-send-email-adrian.hunter@intel.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:perf/core] perf intel-pt: Fix potential loop forever Git-Commit-ID: 9992c2d50a73f442653968a98a9e5f3bf4e769e9 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 9992c2d50a73f442653968a98a9e5f3bf4e769e9 Gitweb: http://git.kernel.org/tip/9992c2d50a73f442653968a98a9e5f3bf4e769e9 Author: Adrian Hunter AuthorDate: Fri, 25 Sep 2015 16:15:34 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 28 Sep 2015 16:44:31 -0300 perf intel-pt: Fix potential loop forever TSC packets contain only 7 bytes of TSC. The 8th byte is assumed to change so infrequently that its value can be inferred. However the logic must cater for a 7 byte wraparound, which it does by adding 1 to the top byte. The existing code was doing that with a while loop even though the addition should only need to be done once. That logic won't work (will loop forever) if TSC wraps around at the 8th byte. Theoretically that would take at least 10 years, unless something else went wrong. And what else could go wrong. Well, if the chunks of trace data are processed out of order, it will make it look like the 7-byte TSC has gone backwards (i.e. wrapped). If that happens 256 times then stuck in the while loop it will be. Fix that by getting rid of the unnecessary while loop. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1443186956-18718-4-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c index 22ba502..9409d01 100644 --- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c +++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c @@ -650,7 +650,7 @@ static int intel_pt_calc_cyc_cb(struct intel_pt_pkt_info *pkt_info) if (data->from_mtc && timestamp < data->timestamp && data->timestamp - timestamp < decoder->tsc_slip) return 1; - while (timestamp < data->timestamp) + if (timestamp < data->timestamp) timestamp += (1ULL << 56); if (pkt_info->last_packet_type != INTEL_PT_CYC) { if (data->from_mtc) @@ -1191,7 +1191,7 @@ static void intel_pt_calc_tsc_timestamp(struct intel_pt_decoder *decoder) timestamp); timestamp = decoder->timestamp; } - while (timestamp < decoder->timestamp) { + if (timestamp < decoder->timestamp) { intel_pt_log_to("Wraparound timestamp", timestamp); timestamp += (1ULL << 56); decoder->tsc_timestamp = timestamp;