Received: by 2002:a05:6500:2018:b0:1fb:9675:f89d with SMTP id t24csp245161lqh; Thu, 30 May 2024 23:04:31 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCU47Bpo6+EWCWU58tSR2HNgjnGW3+sT2Q2oZKACsZrXftWsf2wuChFzw86TZTV8yXooLydw4fewDWLbMZxdoXF9WVnUqTyG0ugdOPwrQw== X-Google-Smtp-Source: AGHT+IG6WHP37CLZBkVdmjS8uI64Z2qPELq63CNGY69BaXBO3ruDU60dLY5EouIJXkDNzMhoj7D6 X-Received: by 2002:a92:c541:0:b0:373:2ba9:4274 with SMTP id e9e14a558f8ab-3748b9dd956mr9264335ab.30.1717135470895; Thu, 30 May 2024 23:04:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717135470; cv=pass; d=google.com; s=arc-20160816; b=q+WUZHLt5K3war6pJ9PN+4nXDve+P9o7N+lOXpNevq/wiD26PyBcTLq2g+n+tIK/cK 7hgg725kwCAxQMrnNJx1CfJEoHxYfEx66wluU/Dpxzg6h8ZzsMXupI06Y7YA57KUdAlH 4yMgza5u8pjSWZF8sLWxaVWefCruEkcrdPjpBjA01iNc5qKxfdykYDHdbiCLs5QGkCI3 36fx7AGTV1I8ZbmUD/XPjT2HXTZ6uL+B+9IrSvYQqhX9cqvUmZRV0yaBUxVd/6ZiBd56 O/F6T//AJAv2pXFqMyim0ryOdg4xXeArrfBI4htewc1ry1XiCCF3Yhhf+p81NYqukniJ VT6Q== 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=n8zYW5+ypc3VPeTGktMSXVu5TPrbTTFQJ0YyrCM+Qys=; fh=CONbk9IM1KeoX7M3ojYzAuH3rM9roTZPm7jJ9UBDXA8=; b=bXen+qsY0Yzq3saUrdVtngzjwOVe9ZiZ1LQqmUirMoJjNUf0XoFQ4JZj9Bom0iovo4 02T17FTikGfGxGvZ52Fbu9LeLYFF3XDHLwR3sUYtJ4A7Upk9bWDlKOMIZ6u4sXH4zlyG BcyqFuUE30EcP1Uoy4JlCMCd3Kk72ZKZiD688IXejT8meE2YePYMzNRB1suhwWZpjrnM r1XPbeRpM2qJpLLwkkscjWx0z/BWiArkTss1k3QmuclEH4/sC5mcwZCBi0fpe3G6BMG5 93CerNPemSQb9cdz71WzrZ0YE6lKh9fJkAp3+gBe6wDh0XC83vRPV6J3oDTQzHXyWC21 Bs+Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-196320-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-196320-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id 41be03b00d2f7-6c355156410si922444a12.208.2024.05.30.23.04.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 May 2024 23:04:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-196320-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-196320-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-196320-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 sv.mirrors.kernel.org (Postfix) with ESMTPS id F0F1B287E8A for ; Fri, 31 May 2024 06:04:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9FCD57D096; Fri, 31 May 2024 06:04:23 +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 13DA7EAE7; Fri, 31 May 2024 06:04:22 +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=1717135463; cv=none; b=ClFjpgKybV2rWyqrOgc9fp7IUYxLZ7XZA5/gQA/+xxE6PiTxVB2FaOApZ1H57tZB8h7vYY9pOFUM1O6ZfcnbZf9/ECX21elpbu6qYrFP5sZP7rHl95CORy6h6C43aG1fRDC4QcPFC1BxnLsHlVDDhLl3F9chkaweUsntCRauo/E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717135463; c=relaxed/simple; bh=Wt3I7rhRO7bYSol/ivwlZxEcVjCjrgihu846oW6r9sY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Fz2jl1AewlPs+RmLCyaNOsBPyk8+ciEGamvpSoRJNjlXp+GlemQstzSlA5z4EpdUA8dxyOo2+6FfzHjdUbLu6J2NfKVkTzhQikKGS2EeDbrsGsJ98lkFIPUXvT59DreRi0JtpwWByDnSJY35IedYLFf9/SDKgZMej0Da8ZGo9x8= 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 408E5C116B1; Fri, 31 May 2024 06:04:18 +0000 (UTC) Date: Fri, 31 May 2024 02:03:46 -0400 From: Steven Rostedt To: "Masami Hiramatsu (Google)" Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Mark Rutland , Mathieu Desnoyers , Andrew Morton , Alexei Starovoitov , Florent Revest , Martin KaFai Lau , bpf , Sven Schnelle , Alexei Starovoitov , Jiri Olsa , Arnaldo Carvalho de Melo , Daniel Borkmann , Alan Maguire , Peter Zijlstra , Thomas Gleixner , Guo Ren Subject: Re: [PATCH 10/20] function_graph: Have the instances use their own ftrace_ops for filtering Message-ID: <20240531020346.6c13e2d4@rorschach.local.home> In-Reply-To: <20240531121241.c586189caad8d31d597f614d@kernel.org> References: <20240525023652.903909489@goodmis.org> <20240525023742.786834257@goodmis.org> <20240530223057.21c2a779@rorschach.local.home> <20240531121241.c586189caad8d31d597f614d@kernel.org> 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 Fri, 31 May 2024 12:12:41 +0900 Masami Hiramatsu (Google) wrote: > On Thu, 30 May 2024 22:30:57 -0400 > Steven Rostedt wrote: > > > On Fri, 24 May 2024 22:37:02 -0400 > > Steven Rostedt wrote: > > > > > From: "Steven Rostedt (VMware)" > > > > > > Allow for instances to have their own ftrace_ops part of the fgraph_ops > > > that makes the funtion_graph tracer filter on the set_ftrace_filter file > > > of the instance and not the top instance. > > > > > > Note that this also requires to update ftrace_graph_func() to call new > > > function_graph_enter_ops() instead of function_graph_enter() so that > > > it avoid pushing on shadow stack multiple times on the same function. > > > > So I found a major design flaw in this patch. > > > > > > > > Co-developed with Masami Hiramatsu: > > > Link: https://lore.kernel.org/linux-trace-kernel/171509102088.162236.15758883237657317789.stgit@devnote2 > > > > > > Signed-off-by: Steven Rostedt (VMware) > > > Signed-off-by: Masami Hiramatsu (Google) > > > Signed-off-by: Steven Rostedt (Google) > > > --- > > > > > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c > > > index 8da0e66ca22d..998558cb8f15 100644 > > > --- a/arch/x86/kernel/ftrace.c > > > +++ b/arch/x86/kernel/ftrace.c > > > @@ -648,9 +648,24 @@ void ftrace_graph_func(unsigned long ip, unsigned long parent_ip, > > > struct ftrace_ops *op, struct ftrace_regs *fregs) > > > { > > > struct pt_regs *regs = &fregs->regs; > > > - unsigned long *stack = (unsigned long *)kernel_stack_pointer(regs); > > > + unsigned long *parent = (unsigned long *)kernel_stack_pointer(regs); > > > + struct fgraph_ops *gops = container_of(op, struct fgraph_ops, ops); > > > + int bit; > > > + > > > + if (unlikely(ftrace_graph_is_dead())) > > > + return; > > > + > > > + if (unlikely(atomic_read(¤t->tracing_graph_pause))) > > > + return; > > > > > > - prepare_ftrace_return(ip, (unsigned long *)stack, 0); > > > + bit = ftrace_test_recursion_trylock(ip, *parent); > > > + if (bit < 0) > > > + return; > > > + > > > + if (!function_graph_enter_ops(*parent, ip, 0, parent, gops)) > > > > So each registered graph ops has its own ftrace_ops which gets > > registered with ftrace, so this function does get called in a loop (by > > the ftrace iterator function). This means that we would need that code > > to detect the function_graph_enter_ops() getting called multiple times > > for the same function. This means each fgraph_ops gits its own retstack > > on the shadow stack. > > Ah, that is my concern and the reason why I added bitmap and stack reuse > code in the ftrace_push_return_trace(). > > > > > I find this a waste of shadow stack resources, and also complicates the > > code with having to deal with tail calls and all that. > > > > BUT! There's good news! I also thought about another way of handling > > this. I have something working, but requires a bit of rewriting the > > code. I should have something out in a day or two. > > Hmm, I just wonder why you don't reocver my bitmap check and stack > reusing code. Are there any problem on it? (Too complicated?) > I actually dislike the use of ftrace itself to do the loop. I rather have fgraph be in control of it. I've come up with a new "subops" assignment, where you can have one ftrace_ops represent multiple sub ftrace_ops. Basically, each fgraph ops can register its own ftrace_ops under a single graph_ops ftrace_ops. The graph_ops will be used to decide what functions call the callback, and then the callback does the multiplexing. This removes the need to touch the architecture code. It can also be used by fprobes to handle the attachments to functions for several different sets of callbacks. I'll send out patches soon. -- Steve