From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754072AbbAES3D (ORCPT ); Mon, 5 Jan 2015 13:29:03 -0500 Received: from mail-la0-f45.google.com ([209.85.215.45]:62341 "EHLO mail-la0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753379AbbAES3C (ORCPT ); Mon, 5 Jan 2015 13:29:02 -0500 MIME-Version: 1.0 In-Reply-To: <20150105164447.GG29390@twins.programming.kicks-ass.net> References: <20150105140754.GF29390@twins.programming.kicks-ass.net> <20150105164447.GG29390@twins.programming.kicks-ass.net> From: Andy Lutomirski Date: Mon, 5 Jan 2015 10:28:39 -0800 Message-ID: Subject: Re: [PATCH 1/2] perf: Move task_pt_regs sampling into arch code To: Peter Zijlstra Cc: Stephane Eranian , Ingo Molnar , Jiri Olsa , root , Andrew Morton , =?UTF-8?B?56em5om/5YiaKOaJv+WImik=?= , Wu Fengguang , Mike Galbraith , Namhyung Kim , Arjan van de Ven , linux-kernel , David Ahern , Paul Mackerras , =?UTF-8?B?56em5om/5YiaKOaJv+WImik=?= , Yanmin Zhang Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 5, 2015 at 8:44 AM, Peter Zijlstra wrote: > On Mon, Jan 05, 2015 at 08:13:49AM -0800, Andy Lutomirski wrote: >> > Just wondering how bad it would be to fill out the actual pt_regs that >> > was previously partially initialized? >> >> Bad, for at least two reasons. >> >> One is that we don't actually know which regs are initialized. bx, >> bp, r12 etc are particularly bad in this regard, due to the FORK_LIKE >> mechanism and similar optimizations. > > Right, but you need to deal with that anyhow. I cheated by assuming they're uninitialized. If we actually wrote -1 over them and they were initialized, then we'd be screwed. > >> The other is that the uninitialized part of task_pt_regs can be used >> for something else entirely. If we have a syscall instruction >> immediately followed by a regular interrupt, then the interrupt's >> hardware frame will overlap task_pt_regs. (I'm not going to claim >> that this design is sensible, but it is what it is. IIRC Denys >> Vlasenko had some patches to partially clean this up.) > > Ah, urgh. Yes painful that. > >> It would be possible to rework the code to avoid an extra pt_regs >> copy, but I don't see an obvious way to do it cleanly. > > Yeah, we'll see how this works, I was just curious on the exact need for > the copy, but if as you say, the original structure might not even exist > properly (even though we have a pointer to it) that's bad (TM). How much freedom do we have to redesign the whole mechanism? Instead of recording the user state from the PMI, we could set a flag so that we'd sample the user state before return to user mode. This would reliably get all of the registers, except in the case where the PMI was part way through the return-to-user code. In that case, we'd want to set another flag to catch the next entry to avoid writing a bogus sample. I don't think we could do this without changing the ABI, though. This would waste ~300 cycles if we set the flag from a fast-path syscall, at least until my magic sysret optimization goes in. --Andy -- Andy Lutomirski AMA Capital Management, LLC