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 9C3CBC77B7E for ; Tue, 2 May 2023 15:27:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233593AbjEBP1s (ORCPT ); Tue, 2 May 2023 11:27:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234450AbjEBP1m (ORCPT ); Tue, 2 May 2023 11:27:42 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 122FC212E for ; Tue, 2 May 2023 08:27:26 -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 9393062601 for ; Tue, 2 May 2023 15:27:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B7DBC433D2; Tue, 2 May 2023 15:27:24 +0000 (UTC) Date: Tue, 2 May 2023 11:27:20 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: 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: <20230502112720.0c0d011b@gandalf.local.home> In-Reply-To: <20230502105353.GO1597476@hirez.programming.kicks-ass.net> References: <20230501200410.3973453-1-indu.bhagat@oracle.com> <20230501200410.3973453-6-indu.bhagat@oracle.com> <20230502105353.GO1597476@hirez.programming.kicks-ass.net> 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, 2 May 2023 12:53:53 +0200 Peter Zijlstra wrote: > > while (entry->nr < entry->max_stack) { > > if (!valid_user_frame(fp, sizeof(frame))) > > break; > > This is broken, the sframe stuff is not NMI safe. First you need to > change perf to emit a forward reference to a 'next' user trace and then > emit the user trace on return-to-user. > > As is, perf does everything in-place from NMI context. Exactly. What I would like to see with the new sframe infrastructure is just a way to tell it "I want a user stack trace before going back to user space". Then all the work can be done in the ptrace path, where it's safe to memory map in the sframe section. It's not like the user space stack frame will change before going back to user space. This will allow for asking for the user space stack trace at any context, because the work will not be done until later. Of course, this may also require user space tooling to be updated to handle this case. Perf may already do that. It would also mean that even if you take multiple profiling hits in one system call, you will only get one user space stack trace. But that's a good thing. As the stack trace doesn't change, and you don't waste ring buffer space with unneeded duplicate stacks. -- Steve