Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp5022678imm; Tue, 16 Oct 2018 04:04:53 -0700 (PDT) X-Google-Smtp-Source: ACcGV63rXzYRZxKo2Dw8dzqowMjZ96rGZZygMSgu1O9GQjzg2GWPF0j3+2Hk68eT3x4HfLa/rx9u X-Received: by 2002:a62:e414:: with SMTP id r20-v6mr21743942pfh.25.1539687893036; Tue, 16 Oct 2018 04:04:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539687893; cv=none; d=google.com; s=arc-20160816; b=cpjo1iZGOjqOctmFdr9kS8LHLA/qPm5FmfWn2orBDk/nc/DdSd81LS/GsvgZhYw5yY oeY8K1QMQqF9E5DsZPRJqhIIBGQUsnl/Vcw0PEsDiOk0K5g4nFAO8Qa4en6668t1cEhv 0bJBTjLaWsQ6L/jmzptdC52n9jaSZP+FJOOw8PKlMyzQlns2bfPC5qgySqyyvCycndEV FkVRA2x+bUH376mgbCwicMDmNgpjARXzIFT/JQIVf57R2fmPVATw+cv69EdMRKhZ2Vf+ xb0BvMwhQqkcH06ktN1ra137rT6Gw1Cy3WpDSwfwiT+ssESYq2Z+LyQUpS4Gn28oBcLI p79A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=5A6a7SHm7h/xoIk8XyGN/p3FWeXlkp9baj+N44jKEv0=; b=doaFSdomnR/6aYh5WU7WrXLDjZSor9UpBnztwZOcaun0GSs3JGWIyHgbVoV8sq3/zo Q2sIgQtygD+oxi8VvDnpvU9GQjsgD+3TDr/TevFxAGXh60afxGNaklAsk8KeJi2UcjKP 8orgBzU0K7eSB3oaaeXV3riYdJwKud9qgneXCVm/JxxrURzIG496mp9V0VjcA2rmN/nu pSxDedhmCdC6f7LiLzeo+dYvlCTWbC0O9RWCsXh3RVt73BvgHxIFxvYebN8k1U6QN2ju v1f87TPrNLlImSw7f25k8l90yMRgsOLinW2JM/IUKU40EbzNYbHxRHiImZs0ZCUGpA0t hUtA== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n5-v6si13501387pgg.186.2018.10.16.04.04.36; Tue, 16 Oct 2018 04:04:53 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727071AbeJPSxi (ORCPT + 99 others); Tue, 16 Oct 2018 14:53:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37380 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726718AbeJPSxh (ORCPT ); Tue, 16 Oct 2018 14:53:37 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 00E0286668; Tue, 16 Oct 2018 11:03:44 +0000 (UTC) Received: from krava (unknown [10.43.17.150]) by smtp.corp.redhat.com (Postfix) with SMTP id 49E746248C; Tue, 16 Oct 2018 11:03:42 +0000 (UTC) Date: Tue, 16 Oct 2018 13:03:41 +0200 From: Jiri Olsa To: Stephane Eranian Cc: Arnaldo Carvalho de Melo , Jiri Olsa , LKML , Peter Zijlstra , Ingo Molnar , Namhyung Kim , Alexander Shishkin Subject: Re: [BUG] perf stat: hangs with -p and process completes Message-ID: <20181016110341.GB18450@krava> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 16 Oct 2018 11:03:44 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 12, 2018 at 02:26:09PM -0700, Stephane Eranian wrote: > Hi, > > I am running into a perf stat issue with the -p option which allows you > to attach to a running process. If that process happens to terminate > while under monitoring > perf hangs in there and never terminates. The proper behavior would be to stop. > I can see the issue in that the attached process is not a child, so > wait() would not work. > > To reproduce: > $ sleep 10 & > $ perf stat -p $! > > doing the same with perf record works, so there is a solution to this problem. yea, we don't poll for the event state change in perf stat, but we do that in perf record.. also because the perf poll code in kernel is originaly meant for tracking the ring buffer state maybe we could return EPOLLIN for alive events without ring buffer.. like below (totaly untested) and add polling for event state into perf stat cc-ing perf folks jirka --- diff --git a/kernel/events/core.c b/kernel/events/core.c index 5a97f34bc14c..b9ee7e7803bf 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -4865,12 +4865,12 @@ static __poll_t perf_poll(struct file *file, poll_table *wait) { struct perf_event *event = file->private_data; struct ring_buffer *rb; - __poll_t events = EPOLLHUP; + __poll_t events = EPOLLIN; poll_wait(file, &event->waitq, wait); if (is_event_hup(event)) - return events; + return EPOLLHUP; /* * Pin the event->rb by taking event->mmap_mutex; otherwise