Re: [PATCH bpf-next v2 1/2] bpf: Reject bpf_timer for PREEMPT_RT

[Peilin Ye <yepeilin@google.com>]

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@google.com/

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