Thread (20 messages) 20 messages, 6 authors, 2020-07-10

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help