Re: [PATCH RFC 3/4] mm, slab: add static key for should_failslab()

[Alexei Starovoitov]

On Sat, Jun 1, 2024 at 1:57 PM Vlastimil Babka <vbabka@xxxxxxx> wrote:
>
> On 5/31/24 6:43 PM, Alexei Starovoitov wrote:
> > On Fri, May 31, 2024 at 2:33 AM Vlastimil Babka <vbabka@xxxxxxx> wrote:
> >>         might_alloc(flags);
> >>
> >> -       if (unlikely(should_failslab(s, flags)))
> >> -               return NULL;
> >> +       if (static_branch_unlikely(&should_failslab_active)) {
> >> +               if (should_failslab(s, flags))
> >> +                       return NULL;
> >> +       }
> >
> > makes sense.
> > Acked-by: Alexei Starovoitov <ast@xxxxxxxxxx>
>
> Thanks :) but please note the cover letter where I explain how I need help
> with the bpftrace side (and ftrace, but that seems sorted). Without that
> part, bpftrace will silently stop doing the injection as the static key will
> remain disabled.

Right. That part was clear. Once this set lands we can add
static key on/off logic either in the kernel directly, or in libbpf.
In the kernel is certainly cleaner.
How will ftrace handle it? I couldn't figure it out from this set.
Ideally key toggle should be a part of generic kprobe attach logic
and not bpf specific, then both bpf and kprobe will work.