On Tue, Jun 20, 2023 at 3:41 AM Barret Rhoden <brho@xxxxxxxxxx> wrote: > > On 6/15/23 12:17, Alexei Starovoitov wrote: > > On Wed, Jun 14, 2023 at 1:32 PM Barret Rhoden <brho@xxxxxxxxxx> wrote: > >> > >> Hi - > >> > >> Would it be possible to add logic to the verifier to handle calling > >> functions within my program (subprograms?) while holding a bpf_spin_lock? > >> > >> Some of my functions are large enough that the compiler won't inline > >> them, so I'll get a BPF_CALL to PC + offset (relative call within my > >> program). Whenever this pops up, I force the compiler to inline the > >> function, but that's brittle. I'd rather just have the ability to call > >> a function. > > > > always_inline works as a workaround, right? > > And it's guaranteed to work, no? > > I'm not sure why you're saying it's brittle. > > yeah, it works. the brittleness comes when i don't mark a function > always_inline, but i don't notice since the compiler was inlining it > anyways. but eventually i make a change and the compiler decides to > not-inline it. e.g. i call the same function again somewhere else in my > program, and now it's worth it to make it a separate function. > > it's not super urgent - and i've been hit by it enough times that i can > usually find the problem if it pops up. > > > It probably generates less performant code, > > so it would be good to add such support. > > It wasn't done earlier, because spin_lock-ed section > > supposed to be short. So the restriction was kinda forcing > > program authors to minimize the lock time. > > Could you please share the example code where you want to use it? > > stuff like this: > > https://github.com/google/ghost-userspace/blob/main/third_party/bpf/biff_flux.bpf.c#L115 > > similar to that one, i have an "AVL tree insert" function that the > compiler didn't want to inline - especially if i called it twice. (the > AVL code hasn't hit our opensource ghost repo yet). > > > Just to make sure we're talking about calling bpf subprograms only > > and you're not requesting to call arbitrary helpers and kfuncs > > while holding the lock. > > Some of the kfuncs can be allowed under lock if there is a real need. > > i was talking about bpf subprogs. though one helper that would be nice > to call while holding a lock is bpf_loop. i've got some loops that i'd > turn into bpf-loops, but can't due to the spinlock. try open-coded iterators instead of bpf_loop(), if you can afford to depend on a slightly newer kernel. See bpf_for() macro in bpf_helpers.h in libbpf > > thanks, > > barret > > >
