Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3177777imu; Fri, 18 Jan 2019 06:10:57 -0800 (PST) X-Google-Smtp-Source: ALg8bN7SvBIKoufPnYFW6M9AIIVmuOLuqpyMETqb0S5aT63ARdoLjTIH9HWn44L9VqXWxHOaYBS/ X-Received: by 2002:a63:1d1d:: with SMTP id d29mr17895172pgd.49.1547820657471; Fri, 18 Jan 2019 06:10:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547820657; cv=none; d=google.com; s=arc-20160816; b=KR9t4r5zZH4UQMNLo4SeFES9QxRyUJm+dm2wzNT0G5fkdYkO4Ioy/dHQIDsbFWvJud 4FfUedET7vrIoDGcCGfULKzn3zwFCWWpPWvA0/7WQNg+jrpzLbQ9USjSAzt8ovzFW/QZ f2hHKJrrZ1ms9q8CE4W6Kl5gk6VzFfBTWprIYcOMDj8wlK4T8mkg1hBHe2SRqgdlmd8n gVRfmVdCCay+yDmTHpVHQjsX7eVEk/Gr3HL+DoTOcprOqiH0+epdeazUGPnV0bT7xFfn CoGqip00t1XgL2hCUXStBSznZ68EnZBhO7epuBbPhXdA+1XVzZxC8BUl/QoJBYv7AExM 8VEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:date:from:dkim-signature; bh=Gd3awAKR+YWHc5QPx8WSxjzY4pO2zBFlyhC7ss7SG1s=; b=0uBRb2ioOhCStq4ykQocITeRbwV44jPgPm0xnc2YUoSqwTDJ22IKOkLkJfyql+lgzD D6LRGzOLvHBF80inJfV7Yq5l5nVnfnJwDXeSBVk4pBnVh0xhl87nMPwJtVtgQA3JKmwo EefXpeF9w3Kcs9F2FtibK/l28AePP+EyR5+IXUi14KXoVEFHb6Llo1+oKrmY7uJsx+wf y+iB4oILIPFQoMeZ5sKIhsaM9gw0jxyx5mqqwSCI2KaapV9DbjgvmhTNs7/rmSzhMEN2 E6vuJY1zEkev95f2oxKHmNsB7Xm6tAcrUL3HtEhiJCaV3blNFsird2s1mGdl8sDc+y8b Z7oA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@maine.edu header.s=google header.b=NQSnxbmG; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t64si4863589pgd.202.2019.01.18.06.10.37; Fri, 18 Jan 2019 06:10:57 -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; dkim=pass header.i=@maine.edu header.s=google header.b=NQSnxbmG; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727326AbfAROJO (ORCPT + 99 others); Fri, 18 Jan 2019 09:09:14 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:37807 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726881AbfAROJN (ORCPT ); Fri, 18 Jan 2019 09:09:13 -0500 Received: by mail-qt1-f196.google.com with SMTP id t33so15268343qtt.4 for ; Fri, 18 Jan 2019 06:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maine.edu; s=google; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=Gd3awAKR+YWHc5QPx8WSxjzY4pO2zBFlyhC7ss7SG1s=; b=NQSnxbmG+VqsbiM2GTgHEsngew/N8D2F7zXpuR6vEwb96LIWv1CL/jwuGuqnThLuj5 Hy7STPEnkgtceNa8ATM3/oz9UgmpGXws3S2zS88mNOc1WajWrc46buWqQ2XfzqQFRBpA DQG5XGtEQmu6zff+B5Kx3khd5gJQfqxA1r2Jo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=Gd3awAKR+YWHc5QPx8WSxjzY4pO2zBFlyhC7ss7SG1s=; b=jm+M37v+J8jHvCoB4XbwBulxHizpEF6kjvb73AmByq06JDIkjEee2WeTmFKhuEYXW+ eludq3F1A3MaKHJjtxXkgvqNdDBbZtugyDP/qsjBtbes192ViMJjIyPYTiF5mYQG6Kz2 12LlyZnP7d/Txi93E5GPtw4DZYk2a0ylbfQrmkBvuADg0+nny8zjN+HfgMhFSz/HrlfX yufKOSQnW2nAlKYbRLeQBN4yNlsJy3g2tYs2dY3lea91VekQq5S3AX/7zJiRL+hvQeBv 4RsaT8BCmNOKrc2BckFVgi/LSn9iIQHslYTbShOAgiOiytuye9hBAiQzxu6nxYjx4oNw 40Iw== X-Gm-Message-State: AJcUukeMXg0TiMxfGT/VkAD71svkDguoMoZZyZb0geBWo7GOZK371/vR 2Ma127lb1PkH5nC/qYhWGtBvSA== X-Received: by 2002:a0c:d6c2:: with SMTP id l2mr15329726qvi.97.1547820552310; Fri, 18 Jan 2019 06:09:12 -0800 (PST) Received: from macbook-air (weaver.eece.maine.edu. [130.111.218.23]) by smtp.gmail.com with ESMTPSA id h35sm61383650qth.59.2019.01.18.06.09.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 Jan 2019 06:09:11 -0800 (PST) From: Vince Weaver X-Google-Original-From: Vince Weaver Date: Fri, 18 Jan 2019 09:09:04 -0500 (EST) X-X-Sender: vince@macbook-air To: Peter Zijlstra cc: linux-kernel@vger.kernel.org, Ingo Molnar , Arnaldo Carvalho de Melo Subject: Re: perf: rdpmc bug when viewing all procs on remote cpu In-Reply-To: <20190118120149.GC27931@hirez.programming.kicks-ass.net> Message-ID: References: <20190118120149.GC27931@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Jan 2019, Peter Zijlstra wrote: > On Fri, Jan 11, 2019 at 04:52:22PM -0500, Vince Weaver wrote: > > On Thu, 10 Jan 2019, Vince Weaver wrote: > > > > > On Thu, 10 Jan 2019, Vince Weaver wrote: > > > > > > > On Thu, 10 Jan 2019, Vince Weaver wrote: > > > > > > > > > However if you create an all-process attached to CPU event: > > > > > perf_event_open(attr, -1, X, -1, 0); > > > > > the mmap event index is set as if this were a valid event and so the rdpmc > > > > > succeeds even though it shouldn't (we're trying to read an event value > > > > > on a remote cpu with a local rdpmc). > > > > so on further looking at the code, it doesn't appear that rdpmc events are > > explicitly marked as unavailable in the attach-cpu or attach-pid case, > > it's just by luck the check for PERF_EVENT_STATE_ACTIVE catches most of > > the cases? > > > > should an explicit check be added to zero out userpg->index in cases where > > the event being measured is running on a different core? > > And how would we konw? We don't know what CPU will be observing the > mmap(). > > RDPMC fundamentally only makes sense on 'self' (either task or CPU). so is this a "don't do that then" thing and I should have PAPI userspace avoid using rdpmc() whenever a proc/cpu was attached to? Or is there a way to have the kernel indicate this? Does the kernel track current CPU and original CPU of the mmap and could zero out the index field in this case? Or would that add too much overhead? Vince