From: "Leon Hwang" <leon.hwang@linux.dev>
To: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
Cc: "bpf" <bpf@vger.kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Eduard" <eddyz87@gmail.com>, "Song Liu" <song@kernel.org>,
"Yonghong Song" <yonghong.song@linux.dev>,
<kernel-patches-bot@fb.com>
Subject: Re: [PATCH bpf-next v2 1/2] bpf: Introduce bpf_in_interrupt kfunc
Date: Mon, 01 Sep 2025 23:12:06 +0800 [thread overview]
Message-ID: <DCHK6T0A6T94.9CMWYIYTG79@linux.dev> (raw)
In-Reply-To: <CAADnVQKkEk=uZ6LBW2yXSAB2huYwpeOdDggaUAzd74_bs_6dcQ@mail.gmail.com>
On Wed Aug 27, 2025 at 6:18 AM +08, Alexei Starovoitov wrote:
> On Mon, Aug 25, 2025 at 8:00 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>>
>>
>> On 25/8/25 23:17, Alexei Starovoitov wrote:
>> > On Mon, Aug 25, 2025 at 6:15 AM Leon Hwang <leon.hwang@linux.dev> wrote:
[...]
>> >
>> > It doesn't scale. Next thing people will ask for hard vs soft irq.
>> >
>>
>> How about adding a 'flags'?
>>
>> Here are the values for 'flags':
>>
>> * 0: return in_interrupt();
>> * 1(NMI): return in_nmi();
>> * 2(HARDIRQ): return in_hardirq();
>> * 3(SOFTIRQ): return in_softirq();
>
> That's an option, but before we argue whether to do as one kfunc with enum
> vs N kfuncs let's explore bpf only option that doesn't involve changing
> the kernel.
>
>> >> +#if defined(CONFIG_X86_64) && !defined(CONFIG_UML)
>> >> + insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, (u32)(unsigned long)&__preempt_count);
>> >
>> > I think bpf_per_cpu_ptr() should already be able to read that per cpu var.
>> >
>>
>> Correct. bpf_per_cpu_ptr() and bpf_this_cpu_ptr() are helpful to read it.
>
> Can you add them as static inline functions to bpf_experimental.h
> and a selftest to make sure it's all working?
> At least for x86 and !PREEMPT_RT.
> Like:
> bool bpf_in_interrupt()
> {
> bpf_this_cpu_ptr(...preempt_count..) & (NMI_MASK | HARDIRQ_MASK |
> SOFTIRQ_MASK);
> }
>
> Of course, there is a danger that kernel implementation might
> diverge from bpf-only bit, but it's a risk we're taking all the time.
I do a PoC of adding bpf_in_interrupt() to bpf_experimental.h.
It works:
extern bool CONFIG_PREEMPT_RT __kconfig __weak;
#ifdef bpf_target_x86
extern const int __preempt_count __ksym;
#endif
struct task_struct__preempt_rt {
int softirq_disable_cnt;
} __attribute__((preserve_access_index));
/* Description
* Report whether it is in interrupt context. Only works on x86.
*/
static inline int bpf_in_interrupt(void)
{
#ifdef bpf_target_x86
int pcnt;
pcnt = *(int *) bpf_this_cpu_ptr(&__preempt_count);
if (!CONFIG_PREEMPT_RT) {
return pcnt & (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_MASK);
} else {
struct task_struct__preempt_rt *tsk;
tsk = (void *) bpf_get_current_task_btf();
return (pcnt & (NMI_MASK | HARDIRQ_MASK)) |
(tsk->softirq_disable_cnt | SOFTIRQ_MASK);
}
#else
return 0;
#endif
}
However, I only test it for !PREEMPT_RT on x86.
I'd like to respin the patchset by moving bpf_in_interrupt() to
bpf_experimental.h.
Thanks,
Leon
next prev parent reply other threads:[~2025-09-01 15:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 13:14 [PATCH bpf-next v2 0/2] bpf: Introduce bpf_in_interrupt kfunc Leon Hwang
2025-08-25 13:15 ` [PATCH bpf-next v2 1/2] " Leon Hwang
2025-08-25 15:17 ` Alexei Starovoitov
2025-08-26 3:00 ` Leon Hwang
2025-08-26 22:18 ` Alexei Starovoitov
2025-09-01 15:12 ` Leon Hwang [this message]
2025-09-02 2:29 ` Alexei Starovoitov
2025-09-03 5:22 ` Leon Hwang
2025-08-25 13:15 ` [PATCH bpf-next v2 2/2] selftests/bpf: Add case to test " Leon Hwang
2025-08-25 17:26 ` Eduard Zingerman
2025-08-26 3:05 ` Leon Hwang
2025-08-26 22:31 ` Eduard Zingerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DCHK6T0A6T94.9CMWYIYTG79@linux.dev \
--to=leon.hwang@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-patches-bot@fb.com \
--cc=martin.lau@linux.dev \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.