Hello, Some map operations via syscalls on hash maps (and some others) disable bpf programs from running on the same CPU with bpf_disable_instrumentation. The provided reason for this is to prevent deadlocks when a nested bpf program tries to access an already held bucket lock. From my understanding, this can happen due to a kprobe on a function called after the lock is acquired. However, htab_lock_bucket already handles this case by returning EBUSY if such a scenario were to happen. Is there any other reason for disabling bpf programs on the CPU? The effect of this is that 1) bpf programs attached to a kprobe or tracepoint in an irq context get skipped while inside bpf_[enable,disable]_instrumentation block but before the preempt_disable via htab_lock_bucket, 2) when CONFIG_PREEMPTION=y and preempt=full then a bpf program running from user context may also get skipped while inside the bpf_[enable,disable]_instrumentation block. Thanks, Usama Saqib.