Messages in this thread | | | Subject | Re: [PATCH v10 1/5] add infrastructure for tagging functions as error injectable | From | Alexei Starovoitov <> | Date | Wed, 20 Dec 2017 09:22:00 -0800 |
| |
On 12/19/17 11:13 PM, Masami Hiramatsu wrote: > On Tue, 19 Dec 2017 18:14:17 -0800 > Alexei Starovoitov <ast@fb.com> wrote: > >> On 12/18/17 10:29 PM, Masami Hiramatsu wrote: >>>> >>>> +#if defined(__KERNEL__) && !defined(__ASSEMBLY__) >>>> +#ifdef CONFIG_BPF_KPROBE_OVERRIDE >>> >>> BTW, CONFIG_BPF_KPROBE_OVERRIDE is also confusable name. >>> Since this feature override a function to just return with >>> some return value (as far as I understand, or would you >>> also plan to modify execution path inside a function?), >>> I think it should be better CONFIG_BPF_FUNCTION_OVERRIDE or >>> CONFIG_BPF_EXECUTION_OVERRIDE. >> >> I don't think such renaming makes sense. >> The feature is overriding kprobe by changing how kprobe returns. >> It doesn't override BPF_FUNCTION or BPF_EXECUTION. > > No, I meant this is BPF's feature which override FUNCTION, so > BPF is a kind of namespace. (Is that only for a function entry > because it can not tweak stackframe at this morment?) > >> The kernel enters and exists bpf program as normal. > > Yeah, but that bpf program modifies instruction pointer, am I correct?
no. bpf side is asking kprobe side to modify it. bpf cannot do such things as modifying IP or any other register directly.
>> >>> Indeed, BPF is based on kprobes, but it seems you are limiting it >>> with ftrace (function-call trace) (I'm not sure the reason why), >>> so using "kprobes" for this feature seems strange for me. >> >> do you have an idea how kprobe override can happen when kprobe >> placed in the middle of the function? > > For example, if you know a basic block in the function, maybe > you can skip a block or something like that. But nowadays > it is somewhat hard because optimizer mixed it up.
still missing how that can work...
| |