[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALOAHbAx+W3-iBS6=FsPPShbEuSSZeyQWvLque+uF9Suwe3-HA@mail.gmail.com>
Date: Thu, 27 Apr 2023 17:57:47 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...gle.com>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
bpf <bpf@...r.kernel.org>, linux-trace-kernel@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next 5/6] bpf: Improve tracing recursion prevention mechanism
On Tue, Apr 25, 2023 at 5:40 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Wed, 19 Apr 2023 15:46:34 -0700
> Alexei Starovoitov <alexei.starovoitov@...il.com> 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 indirectly.
> > 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 between
> 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 = 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.
> The protection is on the trampoline where the bpf program is called.
> Not sure how ftrace can stop BPF or BPF stop ftrace, unless bpf is
> tracing a ftrace callback, or ftrace is tracing a bpf function.
>
> -- Steve
--
Regards
Yafang
Powered by blists - more mailing lists