Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp613200imm; Mon, 21 May 2018 11:13:19 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoPbuq1gN56dPgUmRG84qVvM4N6u1X8ELiTTi7cduDFd7JzNYDnL6+LdqRuUcKu+vGFqA6T X-Received: by 2002:a62:9d5a:: with SMTP id i87-v6mr21230456pfd.190.1526926399434; Mon, 21 May 2018 11:13:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526926399; cv=none; d=google.com; s=arc-20160816; b=TqIHWZhwiaTtu64fjHnNcE0YDqvjTNWaVbLglZnd7CfFYc4esOo5fB+ELiGGxUNpV3 juM35UVuqarGy/yC5STwpPvlyBQS2msoHOGPMWg3MN8XId5ARV5e6M4C//ZPra06BpoF 9p+QJO/JqcT6TBTDedZpGgaEV0CzBco+40zT36OFnvudM1xL8hbwDsUFoNaBDMDURrnF te6IOKFUMSMxQJnrzQugMv618CgsHdoLa8Kotq2HuJTLVRPLMOrr+VY3vxvayd9HBwkf pVS8eJwT0B6mUoSwxtrXoaHLqg1qJSG7nGBqNGpHe3xT1LY9wQI+yFqUtN6CoMjTJqEH s6IA== 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:from:references:cc:to:subject:arc-authentication-results; bh=hSsb9UJKjPIHewuq9mDDu2euTLw8T0aCqpibM9PzefA=; b=U5IFqGLzn5cyB68jpfPtddskS6a5pF3Ja+CRYn1X3GsiMOgAMxY6iTelPAOHsZc9iS BQ4mr+E3ExO3pnftpAX+2siu6ro33CPVpr9XQI4BPGf/1tO+3LFlOPX6nIdXWi137bV5 /GWm3X0AiwC6ZWYTKdo+5o6W5pe4VJwFNWeLfcwdb0ghH8RXspBeAqEMpF28++M8pAzS o3ROkIS8/td1+ffnnuGYAQtJCl5pRJZU2vIl45OIFuG8JHIIQcRFhGu66HlAaewACR8U p2fEK+YYbtx8V+/aZ+ml4mbo0gL8El0yFV+ze+tP+8LTlrF82JssJtMs/EUKH72scd6d LnmA== 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 l3-v6si14160147pfa.368.2018.05.21.11.13.04; Mon, 21 May 2018 11:13:19 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753510AbeEUSLk (ORCPT + 99 others); Mon, 21 May 2018 14:11:40 -0400 Received: from mga18.intel.com ([134.134.136.126]:38628 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753209AbeEUSLi (ORCPT ); Mon, 21 May 2018 14:11:38 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2018 11:11:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,427,1520924400"; d="scan'208";a="41062544" Received: from linux.intel.com ([10.54.29.200]) by fmsmga007.fm.intel.com with ESMTP; 21 May 2018 11:11:37 -0700 Received: from [10.252.10.164] (abudanko-mobl.ccr.corp.intel.com [10.252.10.164]) by linux.intel.com (Postfix) with ESMTP id 9F3EC580393; Mon, 21 May 2018 11:11:34 -0700 (PDT) Subject: Re: [PATCH v2]: perf/x86: store user space frame-pointer value on a sample To: Andy Lutomirski Cc: Peter Zijlstra , Andy Lutomirski , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Andi Kleen , linux-kernel , linux-perf-users@vger.kernel.org References: <31205dc8-b756-e12b-0249-2ed06c2db9c9@linux.intel.com> <20180509145436.GV12217@hirez.programming.kicks-ass.net> <3ecedd91-1c01-6fc5-4648-89eaf5ff0930@linux.intel.com> <20180510101406.GA12217@hirez.programming.kicks-ass.net> <0594eaea-0cab-ea04-c258-5f4770ffeee6@linux.intel.com> <71E4F816-7E0F-4984-B53C-06F8566EAB40@amacapital.net> <36a2c137-8342-4ff4-ddcb-3ac1fe092810@linux.intel.com> From: Alexey Budankov Message-ID: <061c8bbe-0003-b2b5-565d-6b1afe4935f6@linux.intel.com> Date: Mon, 21 May 2018 21:11:33 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 21.05.2018 20:23, Andy Lutomirski wrote: > >> On May 21, 2018, at 9:51 AM, Alexey Budankov wrote: >> >> >> Hi Andy, >>> On 21.05.2018 17:14, Andy Lutomirski wrote: >>> >>>> On May 21, 2018, at 5:44 AM, Alexey Budankov wrote: >>>> >>>> Hi Peter, >>>> >>>>> On 10.05.2018 13:14, Peter Zijlstra wrote: >>>>> On Thu, May 10, 2018 at 12:42:38PM +0300, Alexey Budankov wrote: >>>>>>> The Changelog needs to state that user_regs->bp is in fact valid and >>>>>> >>>>>> That actually was tested on binaries compiled without and with BP exposed >>>>>> and in the latter case proved the value of that change. >>>>> >>>>> Mostly works is not the same as 'always initialized', if there are entry >>>>> paths that do not store that register, then using the value might leak >>>>> values from the kernel stack, which would be bad. >>>>> >>>>> But like said, I think much of the kernel entry code was sanitized with >>>>> the PTI effort and I suspect things are in fact fine now, but lets wait >>>>> for Andy to confirm. >>>> >>>> It looks like, these days, all registers are saved on system calls, just >>>> like you anticipated. >>>> >>>> So BP register value might be stored into the Perf trace on a sample. >>>> >>>> Andy? >>> >>> Hmm, I thought I replied. Yes, they are indeed all saved, but I’m not very excited about committing to doing so forever. But storing BP should be fine. >> >> Thanks for explicit confirmation regarding BP register. >> BTW, do you see any mean to prevent possible unattended regression? >> I guess it could be some compile time assertion or regression testing. > > Write a selftest? Hmm, that might be. It would be good to have some embedded notification when things change. > > The whole perf user regs mechanism is buggy and fragile. I need to massively clean it up at some point. Yep, making Perf user regs part more robust makes great sense. It is critical part of perf/core subsystem providing values of IP,SP,BP registers that are needed for user stack unwinding during Perf trace file post processing. Thanks, Alexey > >> >> Thanks, >> Alexey >> >>> >