Messages in this thread | | | From | KP Singh <> | Date | Thu, 5 Mar 2020 18:43:32 +0100 | Subject | Re: [PATCH bpf-next v4 0/7] Introduce BPF_MODIFY_RET tracing progs |
| |
On 04-Mar 14:17, Alexei Starovoitov wrote: > On Wed, Mar 04, 2020 at 08:18:46PM +0100, KP Singh wrote: > > > > Here is an example of how a fmod_ret program behaves: > > > > int func_to_be_attached(int a, int b) > V> { <--- do_fentry > > > > do_fmod_ret: > > <update ret by calling fmod_ret> > > if (ret != 0) > > goto do_fexit; > > > > original_function: > > > > <side_effects_happen_here> > > > > } <--- do_fexit > > > > ALLOW_ERROR_INJECTION(func_to_be_attached, ERRNO) > > > > The fmod_ret program attached to this function can be defined as: > > > > SEC("fmod_ret/func_to_be_attached") > > int BPF_PROG(func_name, int a, int b, int ret) > > { > > // This will skip the original function logic. > > return -1; > > } > > Applied to bpf-next. Thanks.
Thanks.
> > I think it sets up a great base to parallelize further work.
Totally Agreed!
> > 1. I'm rebasing my sleepable BPF patches on top. > It's necessary to read enviroment variables without the > 'opportunistic copy before hand' hack I saw in your github tree
:) Sleepable BPF would indeed make it much simpler.
> to do bpf_get_env_var() helper. > > 2. please continue on LSM_HOOK patches to go via security tree. > > 3. we need a volunteer to generalize bpf_sk_storage to task and inode structs.
This is quite important, especially for some of the examples we had brought up.
I can take a look at the generalization of bpf_sk_storage.
Thanks! - KP
> This work will be super useful for all bpf tracing too. > Sleepable progs are useful for tracing as well.
| |