Messages in this thread | | | From | Alexei Starovoitov <> | Date | Wed, 7 Dec 2022 13:58:22 -0800 | Subject | Re: [PATCH HID for-next v3 1/5] bpf: do not rely on ALLOW_ERROR_INJECTION for fmod_ret |
| |
On Wed, Dec 7, 2022 at 6:57 AM Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote: > > On Tue, Dec 6, 2022 at 9:48 PM Alexei Starovoitov > <alexei.starovoitov@gmail.com> wrote: > > > > On Tue, Dec 6, 2022 at 6:59 AM Benjamin Tissoires > > <benjamin.tissoires@redhat.com> wrote: > > > > > > The current way of expressing that a non-bpf kernel component is willing > > > to accept that bpf programs can be attached to it and that they can change > > > the return value is to abuse ALLOW_ERROR_INJECTION. > > > This is debated in the link below, and the result is that it is not a > > > reasonable thing to do. > > > > > > Reuse the kfunc declaration structure to also tag the kernel functions > > > we want to be fmodret. This way we can control from any subsystem which > > > functions are being modified by bpf without touching the verifier. > > > > > > > > > Link: https://lore.kernel.org/all/20221121104403.1545f9b5@gandalf.local.home/ > > > Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> > > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> > > > > BPF CI couldn't do its job because of a merge conflict. > > CI only tries to apply the whole series. > > But I tested the patch 1 manually. > > Everything is green on x86-64 and the patch looks good. > > > > Acked-by: Alexei Starovoitov <ast@kernel.org> > > > > Please send the set during the merge window. > > If not we can take just this patch, > > since the series from Viktor Malik would need this patch too. > > > > Thanks a lot for the quick review/tests Alexei. > > I have now taken this patch and the next into the hid tree. > > I actually took this patch through a branch attached to our hid.git > master branch so compared to Linus, it only has this one patch. I also > tagged (and signed) that very same branch with "for-alexei-2022120701" > in case you also want to bring this one in through the bpf tree too.
I didn't find such a branch in your tree, but found that tag and pulled into bpf-next. Thanks!
| |