Re: [PATCH v5 bpf-next 2/5] bpf: Introduce sleepable BPF programs
From: KP Singh <hidden>
Date: 2020-07-01 19:03:14
Also in:
bpf
On Wed, Jul 1, 2020 at 5:14 PM Alexei Starovoitov [off-list ref] wrote:
On Wed, Jul 1, 2020 at 2:17 AM Daniel Borkmann [off-list ref] wrote:quoted
("bpf: Replace cant_sleep() with cant_migrate()"). So perhaps one way to catch bugs for sleepable progs is to add a __might_sleep() into __bpf_prog_enter_sleepable()that's a good idea.quoted
in order to trigger the assertion generally for DEBUG_ATOMIC_SLEEP configured kernels when we're in non-sleepable sections? Still not perfect since the code needs to be exercised first but better than nothing at all.quoted
quoted
What about others like security_sock_rcv_skb() for example which could be bh_lock_sock()'ed (or, generally hooks running in softirq context)?ahh. it's in running in bh at that point? then it should be added to blacklist.Yep.I'm assuming KP will take care of it soon.
I found one other hook, file_send_sigiotask, which mentions "Note that this hook is sometimes called from interrupt." So I think we should add it to the list as well. Given some more due diligence done here and Daniel's proposal of adding __might_sleep() to the __bpf_prog_enter_sleepable() we should be able to iterate on finding other non-sleepable hooks (if they exist) and eventually augmenting the LSM_HOOK macro for a more structured way to store this information. - KP
If not I'll come back to this set some time in August. In the meantime I've pushed patch 1 that removes redundant sync_rcu to bpf-next, since it's independent and it benefits from being in the tree as much as possible.