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 EE241C433EF for ; Fri, 22 Jul 2022 16:25:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230501AbiGVQZ4 (ORCPT ); Fri, 22 Jul 2022 12:25:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233887AbiGVQZy (ORCPT ); Fri, 22 Jul 2022 12:25:54 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 309C9904DC for ; Fri, 22 Jul 2022 09:25:54 -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 ams.source.kernel.org (Postfix) with ESMTPS id E2A90B8293F for ; Fri, 22 Jul 2022 16:25:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15810C341C6; Fri, 22 Jul 2022 16:25:49 +0000 (UTC) Date: Fri, 22 Jul 2022 12:25:48 -0400 From: Steven Rostedt To: Alexei Starovoitov Cc: Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Ingo Molnar , bpf , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo Subject: Re: [RFC] ftrace: Add support to keep some functions out of ftrace Message-ID: <20220722122548.2db543ca@gandalf.local.home> In-Reply-To: <20220722120854.3cc6ec4b@gandalf.local.home> References: <20220722110811.124515-1-jolsa@kernel.org> <20220722072608.17ef543f@rorschach.local.home> <20220722120854.3cc6ec4b@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: bpf@vger.kernel.org On Fri, 22 Jul 2022 12:08:54 -0400 Steven Rostedt wrote: > On Fri, 22 Jul 2022 09:04:29 -0700 > Alexei Starovoitov wrote: > > > ftrace must not peek into bpf specific functions. > > Currently ftrace is causing the kernel to crash. > > What Jiri is proposing is to fix ftrace bug. > > And you're saying nack? let ftrace be broken ? Sounds like a BPF bug to me. Ftrace did nothing to cause this breakage. It was something BPF must have done. What exactly is BPF doing to ftrace locations anyway? > > > > If you don't like Jiri's approach please propose something else. > > So, why not mark it as notrace? That will prevent ftrace from looking at it. > And if for some strange reason you need the mcount/fentry on some internal BPF infrastructure, the work around is to register two ftrace_ops() that have filters to that function. In which case ftrace will force the call to the ftrace iterator loop, and any more ops attached will simply be added to that loop, and ftrace will no longer touch that location. Then you can do whatever you want to it without fear of racing with ftrace. But other than that, we don't need infrastructure to hide any mcount/fentry locations from ftrace. Those were add *for* ftrace. -- Steve