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 80391C00140 for ; Mon, 15 Aug 2022 12:38:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229986AbiHOMiE (ORCPT ); Mon, 15 Aug 2022 08:38:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229623AbiHOMiC (ORCPT ); Mon, 15 Aug 2022 08:38:02 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C3E020F6E; Mon, 15 Aug 2022 05:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=5Ly2/Q/Gj3PGUvgRwRp1buJOUgaq2gWZGs2NW4e5dCw=; b=j01s9Ia7TTbz0+edCRg71r8pvK OPJ21hUqbOgDyr5Xs0qjReFV+8PmFn8bKn17bK2rIvIu5FF1WJCnsxqCFLlzZ5Uil0OtdU272EMJG 5vXELWjfKBx8OOyGHHjmRZQUU14/e3ve+NtHackjQ8hpIxoYaOlNwh9NFshwi02bZ1MvTGBx/Jmee WYtCxOTOZ8usZd6IrqUQA9RV1YOVoqaB95HJQAp4aAA/8t5k9p3wSiNXm8W+dY3R+fdZ8wUdPxGNq T4+ZATJnRe9FZN/Mk7ArdEbj780Kwm0tEJarX9kLfR171evapy3Zl58jpjSmrtnFsPqPMG/npfGGK pKGPvrqQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=worktop.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oNZLf-002fiF-9x; Mon, 15 Aug 2022 12:37:39 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id 4AF07980153; Mon, 15 Aug 2022 14:37:38 +0200 (CEST) Date: Mon, 15 Aug 2022 14:37:38 +0200 From: Peter Zijlstra To: Jiri Olsa Cc: Steven Rostedt , Alexei Starovoitov , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Ingo Molnar , bpf , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , LKML , Josh Poimboeuf Subject: Re: [RFC] ftrace: Add support to keep some functions out of ftrace Message-ID: References: <20220722120854.3cc6ec4b@gandalf.local.home> <20220722122548.2db543ca@gandalf.local.home> <20220722174120.688768a3@gandalf.local.home> <20220813150252.5aa63650@rorschach.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Mon, Aug 15, 2022 at 11:44:32AM +0200, Jiri Olsa wrote: > On Mon, Aug 15, 2022 at 10:03:17AM +0200, Peter Zijlstra wrote: > > On Sat, Aug 13, 2022 at 03:02:52PM -0400, Steven Rostedt wrote: > > > On Fri, 12 Aug 2022 23:18:15 +0200 > > > Jiri Olsa wrote: > > > > > > > the patch below moves the bpf function into sepatate object and switches > > > > off the -mrecord-mcount for it.. so the function gets profile call > > > > generated but it's not visible to ftrace > > > > Why ?!? > > there's bpf dispatcher code that updates bpf_dispatcher_xdp_func > function with bpf_arch_text_poke and that can race with ftrace update > if the function is traced I thought bpf_arch_text_poke() wasn't allowed to touch kernel code and ftrace is in full control of it ?