From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64560C7EE24 for ; Tue, 16 May 2023 17:52:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231694AbjEPRwB (ORCPT ); Tue, 16 May 2023 13:52:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231682AbjEPRwA (ORCPT ); Tue, 16 May 2023 13:52:00 -0400 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F2782103; Tue, 16 May 2023 10:51:57 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-50bc456cc39so21218355a12.1; Tue, 16 May 2023 10:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684259515; x=1686851515; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QBUTYcmTIeDy3K4mzo4idnbb/ymZlSyCtBTIKI1s66w=; b=edRAx+7f6GbWKhApHSW6q+Fu5n5ivFtqfmVm53slR0lBq1xT7rcoJjQMm99uawaSYI FgIAdaHXOn92XV+etSqjAJySNB/CutSg04GRPguAcYvIBcrhvvU9lZNDwJTB6XTwOJMK Jhl/V0tdRN3IVYTLjM5hiwNAZyJiga1Uotn3eo4D21kZRIh3ht4GCJLxVo8c5IX3SBQj PjZ6HfkuPDnv/Aw6fnQk8Jxv0bSrShd2kSXoq9sF4Fk4e8SqEKoDhWdQSYktn1xMXm43 LcYlptkgWY69VB9hXrtNpmZVlxmJcVL3yZYV5X5z+uN8zz6ov6RlVWsh1qRvs63SDiFI bBKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684259515; x=1686851515; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QBUTYcmTIeDy3K4mzo4idnbb/ymZlSyCtBTIKI1s66w=; b=QGGiP/PtYYeqp/3NLOhpx565K2w17xcDA72aV4ODzEippJshhIgk7LN4pxa23UCR15 lgSZOT8yc3dhpGlGxUxQ8c38E2e2htFzUZFnfL32rYBrDiGwhEMp92JdjQ/26mZ1QZbs lyaLbJWsLeZ8vuEcafumGSSpwW5YcL8d2k9Fa958blDhYKuvflYHFCPHCmGA6dPZrwfA 6yEqba+iBBxekCQaChIjAoeITjWxDM5mDCHLCNDhV8zUz7rz8gk/voSW2QipdX6xXffd 4RWQh+Pj+1+N1RjvdYjquGpFa8RkNjaxQiwoTSur2Y7V2sJjIt+OdZ5brLQDiPhE7dLp rO9g== X-Gm-Message-State: AC+VfDyHh0RMX7XnN4vS/ZhiUtmrvSPTCnlyPkz4x47P5/Y79uGokrOe ZFvjDJHN1zI8kbWSfzB+jEYzv/4YGHjUX94iCW8= X-Google-Smtp-Source: ACHHUZ6Seww63RcfA8KHY2lr/e/9upAwRVAwBZUITxn0EMPvS6w8AZju+SUleN3OFPyrlIanhQV+k8UkoWhd5TBxDpk= X-Received: by 2002:a05:6402:151a:b0:50b:faa1:e1d5 with SMTP id f26-20020a056402151a00b0050bfaa1e1d5mr26217570edw.39.1684259515291; Tue, 16 May 2023 10:51:55 -0700 (PDT) MIME-Version: 1.0 References: <20230501200410.3973453-1-indu.bhagat@oracle.com> <20230501200410.3973453-6-indu.bhagat@oracle.com> <20230502105353.GO1597476@hirez.programming.kicks-ass.net> <20230502112720.0c0d011b@gandalf.local.home> <20230516133850.4685e72c@gandalf.local.home> In-Reply-To: <20230516133850.4685e72c@gandalf.local.home> From: Andrii Nakryiko Date: Tue, 16 May 2023 10:51:43 -0700 Message-ID: Subject: Re: [POC 5/5] x86_64: invoke SFrame based stack tracer for user space To: Steven Rostedt Cc: bpf , Peter Zijlstra , Indu Bhagat , linux-toolchains@vger.kernel.org, daandemeyer@meta.com, andrii@kernel.org, kris.van.hees@oracle.com, elena.zannoni@oracle.com, nick.alcock@oracle.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Tue, May 16, 2023 at 10:38=E2=80=AFAM Steven Rostedt wrote: > > On Tue, 16 May 2023 10:25:52 -0700 > Andrii Nakryiko wrote: > > > As discussed in the halls of LSF/MM2023, such lazily mapped .sframe in > > approach won't work with BPF's bpf_get_stack() approach, which expects > > stack trace to be grabbed and returned synchronously from NMI context. > > But we can probably retrofit it into bpf_get_stackid()+STACK_TRACE BPF > > map API. > > Note that we will likely not be able to use sframe in NMI context, and if > that's a requirement, then BPF will need to continue using the method it = is > currently using. Yes, unfortunately. We should give users a way to use sframes, but transition might be slow. > > The best way to access sframe reliable is in normal context. NMI is > special, and really should never had been used to access user space > addresses. That was just a simple solution but not a good one. There's a > lot of hacks just to allow a page fault in NMI context. > See https://lwn.net/Articles/484932/ > > > > > Indu, please cc bpf@vger.kernel.org for future revisions so we can > > track and plan accordingly. Thank you! > > I'll likely be taking over the kernel side of sframes. I'll be happy to > Cc that work to the bpf mailing list. Thanks! > > -- Steve