Received: by 2002:ab2:6203:0:b0:1f5:f2ab:c469 with SMTP id o3csp1038741lqt; Fri, 19 Apr 2024 20:53:20 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWn8ZyAFtR4g5dvI7qiic+eDsXJvsP/kohkokjieMyqLlavD0t3I3y4LEoLA5Hc9tF8oihbS5tpn6YKK2gQQxN/tfcd31Qg2d6XrCMvkQ== X-Google-Smtp-Source: AGHT+IHPigkENOApEet2Mvo5ZdqrNsduSEYr5RbS2Uvr9cc04mg7HU+hYsVX3nf7HHreF/JC6Brh X-Received: by 2002:a05:6a00:9383:b0:6ea:e841:5889 with SMTP id ka3-20020a056a00938300b006eae8415889mr5335819pfb.33.1713585200042; Fri, 19 Apr 2024 20:53:20 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713585200; cv=pass; d=google.com; s=arc-20160816; b=J6oY1SaOlH04WT34OpIcWNXXF+SLCPCaxCBj0gmuWR0N7+wHDFdUSWMOvBw2kXVi9m lH9pgNIAa3u8T02zGDHW+dlVlaAn0umnlRyMJBfc776D2H5dBYHEfUwwqQGNxjhpX4QP gYtA1/H1AxhdqJRRgxLoAf+ujnU8U+io/La5D1vCvE4WZkjKkPv5da4BCXmTwC+q5qe0 vKbZ2qf2is3WCyQA3jyZMjOMDXqFb2LHpoqRDiJdgLnF4DWdOQvenrNZ4GVEtgUp1OFi jnGPensK5YltyCxk/IV9qQ4vKfwa5wVk5B56K7G8b2BXMjsjINtLCw9nFrjzXl9m/UPG r+cw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date; bh=pjdpSImZX6t87rx+5MR9unp7HntdMeSlpJe9hVTUDgc=; fh=VaF/w+FGpk/prTFLJfCoV+GJDmV0Sd6dt8EMZrBTbz0=; b=VoLiMQbM55y+bINgw+OXPHxjAz6QnRDkF1tfdax20rOnEIcUkYax+yEP7Camk5s8ny fZvdwD9+x5IZxp0IMeJFTy0u9hGHxbWgp0N+eGXkUiJEqDtJNR6pMSaZvV6uKGm6XENU GKhsKLykTYfXOEuxOzzaNm9fRSmOZAWrz1RlPO5lGx5akt0MV5ZvBN4iNVuOp+M5u46W HzxtbDgOEtFCDOfX614vpA79IZcJ7dpDliT+vuuSMDCNnq1wIKiwSoWkt1c1FQZw4GSq 1JmLdxhde9qO6/L76Jhy8v0qYFUGDV5Z41Rvq2udJs2p6iFH2JJFhqpxedeDrxri1U+t 1hTA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-152112-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-152112-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id q13-20020a63e94d000000b005d7a13d0be6si4181592pgj.232.2024.04.19.20.53.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Apr 2024 20:53:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-152112-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-152112-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-152112-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 53E82B21490 for ; Sat, 20 Apr 2024 03:53:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7F7C6D534; Sat, 20 Apr 2024 03:53:06 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D9DF92563; Sat, 20 Apr 2024 03:53:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713585185; cv=none; b=R+ekvD/I+MT5TXwte/D4k2dJ38Zthbya2j6ch3lyZP9SNsJbZX3BiyOgsiZ8B/4m+vIdkfJTGzZy672Zt5oXZ391P5OBRXNzYAg1L3/8PYoqWJ9ZiAvvPB0We7sEMLyhJAZyUOPaV5sfkwplf9LWa/7AqhEZhkm1BYqfoeEfQtM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713585185; c=relaxed/simple; bh=6tHXInfbVm0cVL3xkeZnDT/qgKwE8YrS1uVdADz7660=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pbtxZ4q063HKtQqy4TOCIWkkLJscL08At4CBL6iH9kAKdf80pDzznnPGID6ORcGahMRfBeTnhT1T/EjYhWcUelt1XJEGYvfjY3cvxdWzCP4K3aDsEIBs259eUmAO4yqaODlCkZjXGS2nbr5QYpFTZCP25Rl2YTf7+n4kk35lxaI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06856C072AA; Sat, 20 Apr 2024 03:53:02 +0000 (UTC) Date: Fri, 19 Apr 2024 23:52:58 -0400 From: Steven Rostedt To: "Masami Hiramatsu (Google)" Cc: Alexei Starovoitov , Florent Revest , linux-trace-kernel@vger.kernel.org, LKML , Martin KaFai Lau , bpf , Sven Schnelle , Alexei Starovoitov , Jiri Olsa , Arnaldo Carvalho de Melo , Daniel Borkmann , Alan Maguire , Mark Rutland , Peter Zijlstra , Thomas Gleixner , Guo Ren Subject: Re: [PATCH v9 07/36] function_graph: Allow multiple users to attach to function graph Message-ID: <20240419235258.64cada90@rorschach.local.home> In-Reply-To: <171318542015.254850.16655743605260166696.stgit@devnote2> References: <171318533841.254850.15841395205784342850.stgit@devnote2> <171318542015.254850.16655743605260166696.stgit@devnote2> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 15 Apr 2024 21:50:20 +0900 "Masami Hiramatsu (Google)" wrote: > @@ -27,23 +28,157 @@ > > #define FGRAPH_RET_SIZE sizeof(struct ftrace_ret_stack) > #define FGRAPH_RET_INDEX DIV_ROUND_UP(FGRAPH_RET_SIZE, sizeof(long)) > + > +/* > + * On entry to a function (via function_graph_enter()), a new ftrace_ret_stack > + * is allocated on the task's ret_stack with indexes entry, then each > + * fgraph_ops on the fgraph_array[]'s entryfunc is called and if that returns > + * non-zero, the index into the fgraph_array[] for that fgraph_ops is recorded > + * on the indexes entry as a bit flag. > + * As the associated ftrace_ret_stack saved for those fgraph_ops needs to > + * be found, the index to it is also added to the ret_stack along with the > + * index of the fgraph_array[] to each fgraph_ops that needs their retfunc > + * called. > + * > + * The top of the ret_stack (when not empty) will always have a reference > + * to the last ftrace_ret_stack saved. All references to the > + * ftrace_ret_stack has the format of: > + * > + * bits: 0 - 9 offset in words from the previous ftrace_ret_stack > + * (bitmap type should have FGRAPH_RET_INDEX always) > + * bits: 10 - 11 Type of storage > + * 0 - reserved > + * 1 - bitmap of fgraph_array index > + * > + * For bitmap of fgraph_array index > + * bits: 12 - 27 The bitmap of fgraph_ops fgraph_array index I really hate the terminology I came up with here, and would love to get better terminology for describing what is going on. I looked it over but I'm constantly getting confused. And I wrote this code! Perhaps we should use: @frame : The data that represents a single function call. When a function is traced, all the data used for all the callbacks attached to it, is in a single frame. This would replace the FGRAPH_RET_SIZE as FGRAPH_FRAME_SIZE. @offset : This is the word size position on the stack. It would replace INDEX, as I think "index" is being used for more than one thing. Perhaps it should be "offset" when dealing with where it is on the shadow stack, and "pos" when dealing with which callback ops is being referenced. > + * > + * That is, at the end of function_graph_enter, if the first and forth > + * fgraph_ops on the fgraph_array[] (index 0 and 3) needs their retfunc called > + * on the return of the function being traced, this is what will be on the > + * task's shadow ret_stack: (the stack grows upward) > + * > + * | | <- task->curr_ret_stack > + * +--------------------------------------------+ > + * | bitmap_type(bitmap:(BIT(3)|BIT(0)), | > + * | offset:FGRAPH_RET_INDEX) | <- the offset is from here > + * +--------------------------------------------+ > + * | struct ftrace_ret_stack | > + * | (stores the saved ret pointer) | <- the offset points here > + * +--------------------------------------------+ > + * | (X) | (N) | ( N words away from > + * | | previous ret_stack) > + * > + * If a backtrace is required, and the real return pointer needs to be > + * fetched, then it looks at the task's curr_ret_stack index, if it > + * is greater than zero (reserved, or right before poped), it would mask > + * the value by FGRAPH_RET_INDEX_MASK to get the offset index of the > + * ftrace_ret_stack structure stored on the shadow stack. > + */ > + > +#define FGRAPH_RET_INDEX_SIZE 10 Replace SIZE with BITS. > +#define FGRAPH_RET_INDEX_MASK GENMASK(FGRAPH_RET_INDEX_SIZE - 1, 0) #define FGRAPH_FRAME_SIZE_BITS 10 #define FGRAPH_FRAME_SIZE_MASK GENMASK(FGRAPH_FRAME_SIZE_BITS - 1, 0) > + > +#define FGRAPH_TYPE_SIZE 2 > +#define FGRAPH_TYPE_MASK GENMASK(FGRAPH_TYPE_SIZE - 1, 0) #define FGRAPH_TYPE_BITS 2 #define FGRAPH_TYPE_MASK GENMASK(FGRAPH_TYPE_BITS - 1, 0) > +#define FGRAPH_TYPE_SHIFT FGRAPH_RET_INDEX_SIZE > + > +enum { > + FGRAPH_TYPE_RESERVED = 0, > + FGRAPH_TYPE_BITMAP = 1, > +}; > + > +#define FGRAPH_INDEX_SIZE 16 replace "INDEX" with "OPS" as it will be the indexes of ops in the array. #define FGRAPH_OPS_BITS 16 #define FGRAPH_OPS_MASK GENMASK(FGRAPH_OPS_BITS - 1, 0) > +#define FGRAPH_INDEX_MASK GENMASK(FGRAPH_INDEX_SIZE - 1, 0) > +#define FGRAPH_INDEX_SHIFT (FGRAPH_TYPE_SHIFT + FGRAPH_TYPE_SIZE) > + > +/* Currently the max stack index can't be more than register callers */ > +#define FGRAPH_MAX_INDEX (FGRAPH_INDEX_SIZE + FGRAPH_RET_INDEX) FGRAPH_MAX_INDEX isn't even used. Let's delete it. > + > +#define FGRAPH_ARRAY_SIZE FGRAPH_INDEX_SIZE #define FGRAPH_ARRAY_SIZE FGRAPH_INDEX_BITS > + > #define SHADOW_STACK_SIZE (PAGE_SIZE) > #define SHADOW_STACK_INDEX (SHADOW_STACK_SIZE / sizeof(long)) > /* Leave on a buffer at the end */ > -#define SHADOW_STACK_MAX_INDEX (SHADOW_STACK_INDEX - FGRAPH_RET_INDEX) > +#define SHADOW_STACK_MAX_INDEX (SHADOW_STACK_INDEX - (FGRAPH_RET_INDEX + 1)) We probably should rename this is previous patches as well. Unfortunately, it's getting close to the time for me to pick up my wife from the airport to start our vacation. But I think we should rename a lot of these variables to make things more consistent. I'll try to look more at the previous patches as well to make my comments there, when I get some time. Maybe even later today. -- Steve