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

[Leon Hwang <leon.hwang@linux.dev>]

On 10/9/25 06:49, Alexei Starovoitov wrote:
> On Mon, Sep 8, 2025 at 3:42 PM Peilin Ye <yepeilin@google.com> 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@google.com/
> 
> Though switch to bpf_mem_alloc() kinda fixes it,
> it's too late for this release and it's not a complete fix for RT,
> so I think it's better to disable it in the verifier like this patch does.
> 
> Leon, pls respin targeting bpf tree.

My original intention for targeting the bpf-next tree was to ensure that
the new 'timer_interrupt' selftest is skipped when PREEMPT_RT is enabled.

If I respin the patch for the bpf tree, I have to drop the part that
skips the timer_interrupt test case. Should I?

> Also trim the commit log. It's too verbose and not quite correct.
> "kernel will panic"
> That's true only if you have panic-on-warn set.
> Just say that the kernel will warn.
> 

Sure.

I’ll make it more concise and clarify that "the kernel will warn",
rather than saying it will always panic.

Thanks,
Leon