On 2019-10-18 10:46:01 [+0200], Thomas Gleixner wrote: > Clark, > > On Thu, 17 Oct 2019, Clark Williams wrote: > > On Thu, 17 Oct 2019 23:54:07 +0200 (CEST) > > Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > > #2) BPF does allocations in atomic contexts, which is a dubious decision > > > even for non RT. That's related to #1 > > > > I guess my question here is, are the allocations done on behalf of an about-to-run > > BPF program, or as a result of executing BPF code? Is it something we might be able > > to satisfy from a pre-allocated pool rather than kmalloc()? Ok, I need to go dive > > into BPF a bit deeper. > > Sebastion? The data structures use raw_spinlock_t as protection. This is where the atomic context is from. lpm_trie with trie_update_elem() allocates a new element while holding the lock. I tried to make it a spinlock_t which wouldn't have the problem but then https://lore.kernel.org/bpf/4150a0db-18f9-aa93-cdb4-8cf047093740@xxxxxxxxxxxxx/ pointed out that it has been made raw_spinlock_t due to kprobe on -RT. Commit ac00881f92210 ("bpf: convert hashtab lock to raw lock") was "okay" back then (according to Steven Rostedt) but it got wrong with the memory allocation which came in later. In order to tackle one thing at a time, I would say that kprobe isn't our biggest concern… > tglx Sebastian
