Re: [PATCH bpf-next v2 1/2] bpf: Introduce bpf_in_interrupt kfunc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 25, 2025 at 8:00 PM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
>
>
>
> On 25/8/25 23:17, Alexei Starovoitov wrote:
> > On Mon, Aug 25, 2025 at 6:15 AM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
> >>
> >> Filtering pid_tgid is meaningless when the current task is preempted by
> >> an interrupt.
> >>
> >> To address this, introduce the bpf_in_interrupt kfunc, which allows BPF
> >> programs to determine whether they are executing in interrupt context.
> >>
> >> This enables programs to avoid applying pid_tgid filtering when running
> >> in such contexts.
> >>
> >> Signed-off-by: Leon Hwang <leon.hwang@xxxxxxxxx>
> >> ---
> >>  kernel/bpf/helpers.c  |  9 +++++++++
> >>  kernel/bpf/verifier.c | 11 +++++++++++
> >>  2 files changed, 20 insertions(+)
> >>
> >> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> >> index 401b4932cc49f..38991b7b4a9e9 100644
> >> --- a/kernel/bpf/helpers.c
> >> +++ b/kernel/bpf/helpers.c
> >> @@ -3711,6 +3711,14 @@ __bpf_kfunc int bpf_strstr(const char *s1__ign, const char *s2__ign)
> >>         return bpf_strnstr(s1__ign, s2__ign, XATTR_SIZE_MAX);
> >>  }
> >>
> >> +/**
> >> + * bpf_in_interrupt - Check whether it's in interrupt context
> >> + */
> >> +__bpf_kfunc int bpf_in_interrupt(void)
> >> +{
> >> +       return in_interrupt();
> >> +}
> >
> > 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.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux