On 20-Feb 18:17, Alexei Starovoitov wrote: > On Thu, Feb 20, 2020 at 06:52:47PM +0100, KP Singh wrote: > > + > > + /* This is the first program to be attached to the LSM hook, the hook > > + * needs to be enabled. > > + */ > > + if (prog->type == BPF_PROG_TYPE_LSM && tr->progs_cnt[kind] == 1) > > + err = bpf_lsm_set_enabled(prog->aux->attach_func_name, true); > > out: > > mutex_unlock(&tr->mutex); > > return err; > > @@ -336,7 +348,11 @@ int bpf_trampoline_unlink_prog(struct bpf_prog *prog) > > } > > hlist_del(&prog->aux->tramp_hlist); > > tr->progs_cnt[kind]--; > > - err = bpf_trampoline_update(prog->aux->trampoline); > > + err = bpf_trampoline_update(prog); > > + > > + /* There are no more LSM programs, the hook should be disabled */ > > + if (prog->type == BPF_PROG_TYPE_LSM && tr->progs_cnt[kind] == 0) > > + err = bpf_lsm_set_enabled(prog->aux->attach_func_name, false); > > Overall looks good, but I don't think above logic works. > Consider lsm being attached, then fexit, then lsm detached, then fexit detached. > Both are kind==fexit and static_key stays enabled. You're right. I was weary of introducing a new kind (something like BPF_TRAMP_LSM) since they are just fexit trampolines. For now, I added nr_lsm_progs as a member in struct bpf_trampoline and refactored the increment and decrement logic into inline helper functions e.g. static inline void bpf_trampoline_dec_progs(struct bpf_prog *prog, enum bpf_tramp_prog_type kind) { struct bpf_trampoline *tr = prog->aux->trampoline; if (prog->type == BPF_PROG_TYPE_LSM) tr->nr_lsm_progs--; tr->progs_cnt[kind]--; } and doing the check as: if (prog->type == BPF_PROG_TYPE_LSM && tr->nr_lsm_progs == 0) err = bpf_lsm_set_enabled(prog->aux->attach_func_name, false); This should work, If you're okay with it, I will update it in the next revision of the patch-set. - KP