On Wed, Jan 16, 2019 at 11:48:15PM +0100, Daniel Borkmann wrote: > > I think if I'm not mistaken there should still be a possibility for causing a > deadlock, namely if in the middle of the critical section I'm using an LD_ABS > or LD_IND instruction with oob index such that I cause an implicit return 0 > while lock is held. At least I don't see this being caught, probably also for > such case a test_verifier snippet would be good.
good catch. My earlier implementation was reusing check_reference_leak() that is called for both bpf_exit and bpf_ld_abs, but then I realized we cannot call bpf_exit from callee when lock is held and moved that check before prepare_func_exit() forgetting about ldabs. argh. Will fix. > Wouldn't we also need to mark queued spinlock functions as notrace such that > e.g. from kprobe one cannot attach to these causing a deadlock? there is recursion check already, so I'm not sure that is necessary, but will add it since it doesn't hurt and safer indeed.