On Mon, Sep 8, 2025 at 3:42 PM Peilin Ye <yepeilin@xxxxxxxxxx> wrote: > > Hi all, > > > > > [ 35.955287] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 > > FWIW, I was able to reproduce this pr_err() after enabling > CONFIG_PREEMPT_RT and CONFIG_DEBUG_ATOMIC_SLEEP. > > On Mon, Sep 08, 2025 at 12:29:42PM -0700, Eduard Zingerman wrote: > > On Mon, 2025-09-08 at 12:20 -0700, Eduard Zingerman wrote: > > > On Mon, 2025-09-08 at 12:40 +0800, Leon Hwang wrote: > > > > When enable CONFIG_PREEMPT_RT, the kernel will panic when run timer > > > > selftests by './test_progs -t timer': > > > > Related discussions: > > [1] > > - https://lore.kernel.org/bpf/b634rejnvxqu6knjqlijosxrcnxbbpagt4de4pl6env6dwldz2@hoofqufparh5/T/ > > - https://lore.kernel.org/bpf/lhmdi6npaxqeuaumjhmq24ckpul7ufopwzxjbsezhepguqkxag@wolz4r2fazu2/T/ > > [...] > > > > The error is reported because of the kmalloc call in the __bpf_async_init, right? > > > Instead of disabling timers for PREEMPT_RT, would it be possible to > > > switch implementation to use kernel/bpf/memalloc.c:bpf_mem_alloc() instead? > > Just in case - actually there was a patch that does this: > > [2] https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@xxxxxxxxxx/ > > It was then superseded by the patches you linked [1] above however, > since per discussion in [2], "use bpf_mem_alloc() to skip memcg > accounting because it can trigger hardlockups" is a workaround instead > of a proper fix. > > I wonder if this new issue on PREEMPT_RT would justify [2] over [1]? > IIUC, until kmalloc_nolock() becomes available: > > [1] (plus Leon's patch here) means no bpf_timer on PREEMPT_RT, but we > still have memcg accounting for non-PREEMPT_RT; [2] means no memcg > accounting. I didn't comment on the above statement earlier, because I thought you meant "no memcg accounting _inline_", but reading above it sounds that you think that bpf_mem_alloc() doesn't do memcg accounting at all ? That's incorrect. bpf_mem_alloc() always uses memcg accounting, but the usage is nuanced. bpf_global_ma is counted towards root memcg, since it's created during boot. While hash map powered by bpf_mem_alloc is using memcg of the user that created that map.
