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. Thanks, Peilin Ye
