From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754752AbbFKO14 (ORCPT ); Thu, 11 Jun 2015 10:27:56 -0400 Received: from mga01.intel.com ([192.55.52.88]:10367 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751590AbbFKO1y convert rfc822-to-8bit (ORCPT ); Thu, 11 Jun 2015 10:27:54 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,595,1427785200"; d="scan'208";a="586058488" From: "Liang, Kan" To: Arnaldo Carvalho de Melo CC: "linux-kernel@vger.kernel.org" , "Huang, Ying" , "andi@firstfloor.org" Subject: RE: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing Thread-Topic: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing Thread-Index: AQHQo44i3glIe3h0sEG/9i/L0QJfWp2m0lUAgACL4cA= Date: Thu, 11 Jun 2015 14:27:40 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07701875D03@SHSMSX103.ccr.corp.intel.com> References: <1433922364-22580-1-git-send-email-kan.liang@intel.com> <20150611140614.GC2696@kernel.org> In-Reply-To: <20150611140614.GC2696@kernel.org> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Em Wed, Jun 10, 2015 at 03:46:04AM -0400, kan.liang@intel.com escreveu: > > perf top reads all threads' /proc/xxx/maps. If there is any threads > > which generating a keeping growing huge /proc/xxx/maps, perf will do > > infinite loop in perf_event__synthesize_mmap_events. > > This patch fixes this issue by adding a time out to force stop this > > kind of endless mmap processing. > > > > Reported-by: Huang, Ying > > Signed-off-by: Kan Liang > > So we will silently stop processing those events? > > We will make progress, no doubt, but I think the user needs to be warned > about this situation, so that later on when/if samples for those maps > appear and don't get resolved at least we will know that this is the reason. > I will add warning message for this kind of time out. Thanks, Kan > - Arnaldo > > > --- > > tools/perf/util/event.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index > > 793b150..0df7f2a9 100644 > > --- a/tools/perf/util/event.c > > +++ b/tools/perf/util/event.c > > @@ -213,6 +213,8 @@ static int perf_event__synthesize_fork(struct > perf_tool *tool, > > return 0; > > } > > > > +#define MMAP_TIMEOUT (50 * 1000000ULL) > > + > > int perf_event__synthesize_mmap_events(struct perf_tool *tool, > > union perf_event *event, > > pid_t pid, pid_t tgid, > > @@ -222,6 +224,7 @@ int > perf_event__synthesize_mmap_events(struct > > perf_tool *tool, { > > char filename[PATH_MAX]; > > FILE *fp; > > + unsigned long long t; > > int rc = 0; > > > > if (machine__is_default_guest(machine)) > > @@ -240,6 +243,7 @@ int > perf_event__synthesize_mmap_events(struct perf_tool *tool, > > } > > > > event->header.type = PERF_RECORD_MMAP2; > > + t = rdclock(); > > > > while (1) { > > char bf[BUFSIZ]; > > @@ -250,7 +254,8 @@ int > perf_event__synthesize_mmap_events(struct perf_tool *tool, > > size_t size; > > ssize_t n; > > > > - if (fgets(bf, sizeof(bf), fp) == NULL) > > + if ((fgets(bf, sizeof(bf), fp) == NULL) || > > + ((rdclock() - t) > MMAP_TIMEOUT)) > > break; > > > > /* ensure null termination since stack will be reused. */ > > -- > > 1.8.3.1