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 7D658C77B7A for ; Tue, 16 May 2023 17:38:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230117AbjEPRi6 (ORCPT ); Tue, 16 May 2023 13:38:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229533AbjEPRi6 (ORCPT ); Tue, 16 May 2023 13:38:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 170DA6E99 for ; Tue, 16 May 2023 10:38:56 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 94F72611D1 for ; Tue, 16 May 2023 17:38:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BCF41C433D2; Tue, 16 May 2023 17:38:53 +0000 (UTC) Date: Tue, 16 May 2023 13:38:50 -0400 From: Steven Rostedt To: Andrii Nakryiko 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 Subject: Re: [POC 5/5] x86_64: invoke SFrame based stack tracer for user space Message-ID: <20230516133850.4685e72c@gandalf.local.home> In-Reply-To: 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> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org 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. 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. -- Steve