On Thu, Mar 28, 2024 at 7:55 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > On Thu, Mar 28, 2024 at 5:50 PM Maximilian Luz <luzmaximilian@xxxxxxxxx> wrote: > > > > If I understand correctly, it enters an atomic section in > > qcom_tzmem_alloc() and then tries to schedule somewhere down the line. > > So this shouldn't be qseecom specific. > > > > I should probably also say that I'm currently testing this on a patched > > v6.8 kernel, so there's a chance that it's my fault. However, as far as > > I understand, it enters an atomic section in qcom_tzmem_alloc() and then > > later tries to expand the pool memory with dma_alloc_coherent(). Which > > AFAIK is allowed to sleep with GFP_KERNEL (and I guess that that's the > > issue here). > > > > I've also tried the shmem allocator option, but that seems to get stuck > > quite early at boot, before I even have usb-serial access to get any > > logs. If I can find some more time, I'll try to see if I can get some > > useful output for that. > > > > Ah, I think it happens here: > > + guard(spinlock_irqsave)(&pool->lock); > + > +again: > + vaddr = gen_pool_alloc(pool->genpool, size); > + if (!vaddr) { > + if (qcom_tzmem_try_grow_pool(pool, size, gfp)) > + goto again; > > We were called with GFP_KERNEL so this is what we pass on to > qcom_tzmem_try_grow_pool() but we're now holding the spinlock. I need > to revisit it. Thanks for the catch! > > Bart Can you try the following tree? https://git.codelinaro.org/bartosz_golaszewski/linux.git topic/shm-bridge-v10 gen_pool_alloc() and gen_pool_add_virt() can be used without external serialization. We only really need to protect the list of areas in the pool when adding a new element. We could possibly even use list_add_tail_rcu() as it updates the pointers atomically and go lockless. Bart