On Mon, 12 Dec 2022, Benjamin Tissoires wrote: > If I compile the kernel with LLVM=1, the function > bpf_prog_put_deferred() is optimized in a weird way: if we are not in > irq, the function is inlined into __bpf_prog_put(), but if we are, the > function is still kept around as it is called in a scheduled work item. > > This is something I completely overlooked: I assume that if the function > would be inlined, the HID entrypoint BPF preloaded object would not be > able to bind, thus deactivating HID-BPF safely. But if a function can be > both inlined and not inlined, then I have no guarantees that my cleanup > call will be called. Meaning that a HID device might believe there is > still a bpf function to call. And things will get messy, with kernel > crashes and others. > > An easy "fix" would be to tag bpf_prog_put_deferred() with "noinline", > but it just feels wrong to have that for this specific reason. > > AFAICT, gcc is not doing that optimisation, but nothing prevents it > from doing it, and suddenly that will be a big whole in the kernel. It's not doing it on this particular function, but in general it's actually quite common for gcc to inline a function in some callsites and leave it out-of-line in others (we are dealing with that in livepatching), so I agree it has to be taken into account irrespective of the compiler used. > As much as I wish I had another option, I think for the sake of everyone > (and for my future holidays) I'll postpone HID-BPF to 6.3. Thanks, -- Jiri Kosina SUSE Labs
