Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7551651yba; Thu, 2 May 2019 11:52:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqwxZ0l8igfjce7cmLCzd102kspkIULEH88M105u+tdHLwKVSOPqp7MaPXDpIvojUKT0z+dq X-Received: by 2002:a63:610f:: with SMTP id v15mr5681972pgb.128.1556823172764; Thu, 02 May 2019 11:52:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556823172; cv=none; d=google.com; s=arc-20160816; b=hupUupFhdHyxUSHyeQRi/N2msvIEHNqgHMi4z0H6GRXReCK73GPEldafd1Fd5mC/r/ M4bCt56O1FZ95VmhEweWxaGKBdCDODHUNUi+9I7gVBBxZLoy8x2yv6yP5n7yqkFEf1xV yqpgFAZhqrCzRum/lrlLr9g7Z2W1SrCRgynQKBWMlNE6jzPY1D2snvO9Xz5i6tNzfjc8 6IAic3/KIW9Vq18yFYDpHvSvOnJYTA6oKBFG4irUd3UrTVSdGFaAs9Zs4ePMKlChfCi5 M0LW+APxlpDnTbfV3vWZ/5B7rqKPfYEVG7H7Lkl4TXMVXR6t1/axYKz71ulnDalPKPPr CLGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=jRZt+D8O8akEME1deiXcwDybfKiwpthrXzyaDQKQw+o=; b=Vu1ZjgTirezjeBtz3yTSmXKZojWZVRzHHvwLUaj1TyBMg2J0m2BasvkvjJOd0L047O NLSOgm5fqM0f1RqfFAXfxzybqJ7lf1EmEBkdwatiF057azXr7NtnyS6sdrZpcCA0IrD9 Ap0CxNUaczS/F2MJBJ/tTYXIh/vfB1w4ona8CHo1a4hl4ViXjLkzVgL4JTQA0CdiYHKB PtgHEyKs/o0hpz4/xx8FlSIfjtWTmKD2T08ifzHJTKZwK1Mh+J7S92kM8onP8LXSKzte 8IN7/WZLyGqpuychipfl5awxaQcbGFIKRyyE5aoppDDv3zlqJwRc1DSnTTVQuPNDBo1k BAxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=DOe1Odxc; 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 x2si34136702pgf.272.2019.05.02.11.52.35; Thu, 02 May 2019 11:52:52 -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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=DOe1Odxc; 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 S1726175AbfEBSvk (ORCPT + 99 others); Thu, 2 May 2019 14:51:40 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:46611 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725962AbfEBSvk (ORCPT ); Thu, 2 May 2019 14:51:40 -0400 Received: by mail-lj1-f194.google.com with SMTP id h21so3120327ljk.13 for ; Thu, 02 May 2019 11:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jRZt+D8O8akEME1deiXcwDybfKiwpthrXzyaDQKQw+o=; b=DOe1Odxc1gK8brv9R5zvAAh8GUyJ0YnhuXPXnXKLY6rlveLN+SrMsrIhlmdzjwzc3A +gpmg7E+x+gFu/OGE9tnfORqGbP7/EJEKg5bLaODW4PNZqGswJ1xp/er7T39ChKACNGs gUroHv8DdOMTYzXZZhWIDTz6VqI7ZdBhWPnGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jRZt+D8O8akEME1deiXcwDybfKiwpthrXzyaDQKQw+o=; b=dbQEldQIp6waaxS/AYplu6/6/6uZ1OMImx3iCQXBM3pDWhVjr0RT9xe1UyAtRS2CRL 7SY2RaaNzj2tOI7jBuTt3sub52SjPbzQiA5o97fUQVRUhO3M8TK/s9oRsYmP1xGsmFsp Yp6/Ok0GqRAV3rvFJ1XSjemDl6T/ORssdDgHDi8gEsM/Micgx6BbCZXIr3Un1Bh9jXTw 6ZV0Ed3z3hb46HMw7292i6HS2kQkgMsAO59Ccy4eofIh3TpZ2E+Pgi2dgrVQAnKQjHRz sEgdliL9RiTEtjyLwi/oqhI2LJStzmNVA8PIqqoro6zZhSTjss0s6BzHuuYtSbdccBp6 kBlw== X-Gm-Message-State: APjAAAWuBr60qMEtYRpiSP0m1uyaR/R5lPcEtbfZ1vJSj1FHfPFpd2BJ RjJ4cr/536NnAf7SyQ7XlkH1Y9TwKA8= X-Received: by 2002:a2e:9283:: with SMTP id d3mr2857941ljh.8.1556823097483; Thu, 02 May 2019 11:51:37 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id z6sm2832450ljb.56.2019.05.02.11.51.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 May 2019 11:51:37 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id e18so3165617lja.5 for ; Thu, 02 May 2019 11:51:37 -0700 (PDT) X-Received: by 2002:a2e:9a84:: with SMTP id p4mr2295002lji.22.1556822633649; Thu, 02 May 2019 11:43:53 -0700 (PDT) MIME-Version: 1.0 References: <20190501202830.347656894@goodmis.org> <20190501203152.397154664@goodmis.org> <20190501232412.1196ef18@oasis.local.home> <20190502162133.GX2623@hirez.programming.kicks-ass.net> <20190502181811.GY2623@hirez.programming.kicks-ass.net> In-Reply-To: <20190502181811.GY2623@hirez.programming.kicks-ass.net> From: Linus Torvalds Date: Thu, 2 May 2019 11:43:37 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions To: Peter Zijlstra Cc: Steven Rostedt , Linux List Kernel Mailing , Ingo Molnar , Andrew Morton , Andy Lutomirski , Nicolai Stange , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , Shuah Khan , Konrad Rzeszutek Wilk , Tim Chen , Sebastian Andrzej Siewior , Mimi Zohar , Juergen Gross , Nick Desaulniers , Nayna Jain , Masahiro Yamada , Joerg Roedel , "open list:KERNEL SELFTEST FRAMEWORK" , stable Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 2, 2019 at 11:18 AM Peter Zijlstra wrote: > > We could fix this by not using the common exit path on int3; not sure we > want to go there, but that is an option. I don't think it's an option in general, because *some* int3 invocations will need all the usual error return. But I guess we could make "int3 from kernel space" special. I'm not sure how much that would help, but it might be worth looking into. > ARGH; I knew it was too pretty :/ Yes, something like what you suggest > will be needed, I'll go look at that once my brain recovers a bit from > staring at entry code all day. Looks like it works based on your other email. What would it look like with the "int3-from-kernel is special" modification? Because *if* we can make the "kernel int3" entirely special, that would make the "Eww factor" much less of this whole thing. I forget: is #BP _only_ for the "int3" instruction? I know we have really nasty cases with #DB (int1) because of "pending exceptions happen on the first instruction in kernel space", and that makes it really really nasty to handle with all the stack switch and %cr3 handling etc. But if "int3 from kernel space" _only_ happens on actual "int3" instructions, then we really could just special-case that case. We'd know that %cr3 has been switched, we'd know that we don't need to do fsgs switching, we'd know we already have a good stack and percpu data etc set up. So then special casing #BP would actually allow us to have a simple and straightforward kernel-int3-only sequence? And then having that odd stack setup special case would be *much* more palatable to me. Linus