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 7F632C77B61 for ; Thu, 27 Apr 2023 12:36:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243373AbjD0MgX (ORCPT ); Thu, 27 Apr 2023 08:36:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229636AbjD0MgW (ORCPT ); Thu, 27 Apr 2023 08:36:22 -0400 Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D989B3AAA; Thu, 27 Apr 2023 05:36:21 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-74de7635180so809485185a.3; Thu, 27 Apr 2023 05:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682598981; x=1685190981; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uamYaAPiGbEuD/CCuWzrQEEft21M2zokyUeiq+isD7s=; b=BTlbPFOcy9ohq/rnIcEzr3ktsmGoIkLS5TIak2p0WjRjIS7tVD1nIqK8H28Io6XqVb 9aLFzRITd38OHn++1iixe4l+zH9eVbZwDAfhDkBPWusPk/VSHTt3diuofZ1nXTms4rWa JJDnLuoNxKzEPHBsTTAesrqHvIflWeuCV+ypelKfuvD4O+TPSpqMCXAzeoegikWjB/Xn oB//Q9Oj0JVMjfEMXdE+932BDwJurikQ3prEJSDaerswpy8Wg2pAA2X1sKEPI4tHB6Go ZHMRvXK14JUWYrPAmxUScss3xazUqYC7wB2ZNdtCocebfo9MWUezS6nhOC52uXfScmbO Xkvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682598981; x=1685190981; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uamYaAPiGbEuD/CCuWzrQEEft21M2zokyUeiq+isD7s=; b=kbVIus5Zlt1nLD/D602IavKg+fKqXa8euUDk5wNeoKeKslEGCRlnf/+FguDfLS7nNr J6OS79tYntZJI5mU8S0NEMJtcagDbH23QkSrOQTJWkoaC/7KZbmAFJ9+aJ/EqObjj/Y3 VIpIh7k+9564H7g/f607IQDM+muou5KLm35tSuqVBKwA3ZWSyDUCZf6NWXsF9ztJEqZN XR+OHdg9S99O2R8wQuWrQdVUn9uXvDjenVOGaTr1ah+kcyRFgCTsbBT6N7BbxoHDkBMl U3PAvPdg5UG624P4gmPagdoy7DtOAxfHxAF2cW6HB6nTfR+GG2xwJ9N0XXgOPCTS1vNJ IiWg== X-Gm-Message-State: AC+VfDxH0DdzGYSmcdfON4HaNzKOiGX6g63VQOGlZ8rfJB4Iu66akujw aDTw+E6YwojY5QuMYT4n6TkG8IA+UJ1Met7kKKQ= X-Google-Smtp-Source: ACHHUZ6z1cQlttoN0k2H76P2WsRE9QHnUy28HBxx03rn8CVmetWUfgyzpbwJvo84hWza6TQwkxJK0ed6dgn0FdEClcE= X-Received: by 2002:ad4:5fca:0:b0:615:29ab:e4c6 with SMTP id jq10-20020ad45fca000000b0061529abe4c6mr2008193qvb.45.1682598981060; Thu, 27 Apr 2023 05:36:21 -0700 (PDT) MIME-Version: 1.0 References: <20230417154737.12740-1-laoar.shao@gmail.com> <20230417154737.12740-6-laoar.shao@gmail.com> <20230417201457.c43xfcukjzm4u6vx@dhcp-172-26-102-232.dhcp.thefacebook.com> <20230424174049.1c9e54dd@rorschach.local.home> In-Reply-To: From: Yafang Shao Date: Thu, 27 Apr 2023 20:35:45 +0800 Message-ID: Subject: Re: [PATCH bpf-next 5/6] bpf: Improve tracing recursion prevention mechanism To: Steven Rostedt , Alexei Starovoitov Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Masami Hiramatsu , bpf , linux-trace-kernel@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-trace-kernel@vger.kernel.org On Thu, Apr 27, 2023 at 8:15=E2=80=AFPM Yafang Shao = wrote: > > On Thu, Apr 27, 2023 at 5:57=E2=80=AFPM Yafang Shao wrote: > > > > On Tue, Apr 25, 2023 at 5:40=E2=80=AFAM Steven Rostedt wrote: > > > > > > On Wed, 19 Apr 2023 15:46:34 -0700 > > > Alexei Starovoitov wrote: > > > > > > > No. Just one prog at entry into any of the kernel functions > > > > and another prog at entry of funcs that 1st bpf prog called indirec= tly. > > > > Like one prog is tracing networking events while another > > > > is focusing on mm. They should not conflict. > > > > > > You mean that you have: > > > > > > function start: > > > __bpf_prog_enter_recur() > > > bpf_program1() > > > __bpf_prog_enter_recur() > > > bpf_program2(); > > > __bpf_prog_exit_recur() > > > __bpf_prog_exit_recur() > > > > > > rest of function > > > > > > That is, a bpf program can be called within another bpf pogram betwee= n > > > the prog_enter and prog_exit(), that is in the same context (normal, > > > softirq, irq, etc)? > > > > > > > Right, that can happen per my verification. Below is a simple bpf > > program to verify it. > > > > struct { > > __uint(type, BPF_MAP_TYPE_LPM_TRIE); > > __type(key, __u64); > > __type(value, __u64); > > __uint(max_entries, 1024); > > __uint(map_flags, BPF_F_NO_PREALLOC); > > } write_map SEC(".maps"); > > > > __u64 key; > > > > SEC("fentry/kernel_clone") > > int program1() > > { > > __u64 value =3D 1; > > > > bpf_printk("before update"); > > // It will call trie_update_elem and thus trigger program2. > > bpf_map_update_elem(&write_map, &key, &value, BPF_ANY); > > __sync_fetch_and_add(&key, 1); > > bpf_printk("after update"); > > return 0; > > } > > > > SEC("fentry/trie_update_elem") > > int program2() > > { > > bpf_printk("trie_update_elem"); > > return 0; > > } > > > > The result as follows, > > > > kubelet-203203 [018] ....1 9579.862862: > > __bpf_prog_enter_recur: __bpf_prog_enter_recur > > kubelet-203203 [018] ...11 9579.862869: bpf_trace_printk: > > before update > > kubelet-203203 [018] ....2 9579.862869: > > __bpf_prog_enter_recur: __bpf_prog_enter_recur > > kubelet-203203 [018] ...12 9579.862870: bpf_trace_printk: > > trie_update_elem > > kubelet-203203 [018] ....2 9579.862870: > > __bpf_prog_exit_recur: __bpf_prog_exit_recur > > kubelet-203203 [018] ...11 9579.862870: bpf_trace_printk: > > after update > > kubelet-203203 [018] ....1 9579.862871: > > __bpf_prog_exit_recur: __bpf_prog_exit_recur > > > > Note that we can't trace __bpf_prog_enter_recur and > > __bpf_prog_exit_recur, so we have to modify the kernel to print them. > > > > ... However, surprisingly it still works even after this patchset is > applied, because the hardirq/softirq flag is set when the program2 is > running, see also the flags in the above trace_pipe output. Is that > expected ?! > I need some time to figure it out, but maybe you have a quick answer... Answer it by myself, that is because of the allowing-one-single-recursion rule. I misread the trace flags before. Sorry about the noise. --=20 Regards Yafang