This path introduces several kfuncs to help BPF programs determine their
current execution context. When hooking functions for statistics, we often
need to use current->comm to get the process name.

However, these hooked functions can be called from either process context
or interrupt context. When called from interrupt context, the current we
obtain may refer to the process that was interrupted, which may not be
what we need.

These new kfuncs expose APIs that allow users to determine the actual
execution context.

Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 kernel/bpf/helpers.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index b9ec6ee21c94..e09c70b4eaea 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -4252,6 +4252,47 @@ __bpf_kfunc int bpf_task_work_schedule_resume(struct task_struct *task, struct b
 	return bpf_task_work_schedule(task, tw, map__map, callback, aux__prog, TWA_RESUME);
 }
 
+/**
+ * bpf_in_nmi_context - Check whether we are serving NMI
+ *
+ * Return: true if we are serving NMI
+ */
+__bpf_kfunc bool bpf_in_nmi_context(void)
+{
+	return in_nmi();
+}
+
+/**
+ * bpf_in_hardirq_context - Check whether we are serving hard irq
+ *
+ * Return: true if we are serving hard irq
+ */
+__bpf_kfunc bool bpf_in_hardirq_context(void)
+{
+	return in_hardirq();
+}
+
+/**
+ * bpf_in_softirq_context - Check whether we are serving soft irq
+ *
+ * Return: true if we are serving soft irq
+ */
+__bpf_kfunc bool bpf_in_softirq_context(void)
+{
+	/* in_softirq() has been deprecated */
+	return in_serving_softirq();
+}
+
+/**
+ * bpf_in_task_context - Check whether we are in task context
+ *
+ * Return: true if we are in task context
+ */
+__bpf_kfunc bool bpf_in_task_context(void)
+{
+	return in_task();
+}
+
 __bpf_kfunc_end_defs();
 
 static void bpf_task_work_cancel_scheduled(struct irq_work *irq_work)
@@ -4429,6 +4470,10 @@ BTF_ID_FLAGS(func, bpf_cgroup_read_xattr, KF_RCU)
 BTF_ID_FLAGS(func, bpf_stream_vprintk, KF_TRUSTED_ARGS)
 BTF_ID_FLAGS(func, bpf_task_work_schedule_signal, KF_TRUSTED_ARGS)
 BTF_ID_FLAGS(func, bpf_task_work_schedule_resume, KF_TRUSTED_ARGS)
+BTF_ID_FLAGS(func, bpf_in_softirq_context)
+BTF_ID_FLAGS(func, bpf_in_hardirq_context)
+BTF_ID_FLAGS(func, bpf_in_task_context)
+BTF_ID_FLAGS(func, bpf_in_nmi_context)
 BTF_KFUNCS_END(common_btf_ids)
 
 static const struct btf_kfunc_id_set common_kfunc_set = {
-- 
2.43.0

Hi Jiayuan,

kernel test robot noticed the following build warnings:

[auto build test WARNING on bpf-next/master]

url:    https://github.com/intel-lab-lkp/linux/commits/Jiayuan-Chen/bpf-Add-kfuncs-for-detecting-execution-context/20251022-193551
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link:    https://lore.kernel.org/r/20251022113412.352307-2-jiayuan.chen%40linux.dev
patch subject: [PATCH bpf-next v1 1/2] bpf: Add kfuncs for detecting execution context
config: alpha-randconfig-r123-20251023 (https://download.01.org/0day-ci/archive/20251024/202510242353.hCaLzqVt-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251024/202510242353.hCaLzqVt-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510242353.hCaLzqVt-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
   kernel/bpf/helpers.c:1199:21: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected unsigned long long ( *[usertype] callback_fn )( ... ) @@     got void [noderef] __rcu * @@
   kernel/bpf/helpers.c:1199:21: sparse:     expected unsigned long long ( *[usertype] callback_fn )( ... )
   kernel/bpf/helpers.c:1199:21: sparse:     got void [noderef] __rcu *
   kernel/bpf/helpers.c:2480:18: sparse: sparse: symbol 'bpf_task_release_dtor' was not declared. Should it be static?
   kernel/bpf/helpers.c:2510:18: sparse: sparse: symbol 'bpf_cgroup_release_dtor' was not declared. Should it be static?
>> kernel/bpf/helpers.c:4260:18: sparse: sparse: symbol 'bpf_in_nmi_context' was not declared. Should it be static?
   kernel/bpf/helpers.c:2976:18: sparse: sparse: context imbalance in 'bpf_rcu_read_lock' - wrong count at exit
   kernel/bpf/helpers.c:2981:18: sparse: sparse: context imbalance in 'bpf_rcu_read_unlock' - unexpected unlock

vim +/bpf_in_nmi_context +4260 kernel/bpf/helpers.c

  4254	
  4255	/**
  4256	 * bpf_in_nmi_context - Check whether we are serving NMI
  4257	 *
  4258	 * Return: true if we are serving NMI
  4259	 */
> 4260	__bpf_kfunc bool bpf_in_nmi_context(void)
  4261	{
  4262		return in_nmi();
  4263	}
  4264	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

On 2025/10/22 19:33, Jiayuan Chen wrote:
> This path introduces several kfuncs to help BPF programs determine their
> current execution context. When hooking functions for statistics, we often
> need to use current->comm to get the process name.
>
> However, these hooked functions can be called from either process context
> or interrupt context. When called from interrupt context, the current we
> obtain may refer to the process that was interrupted, which may not be
> what we need.
>
> These new kfuncs expose APIs that allow users to determine the actual
> execution context.

Hi Jiayuan,

Rather than introducing multiple kfuncs to determine the current
execution context, this can already be achieved by using the
'bpf_this_cpu_ptr()' helper to read the underlying preemption count.

Please refer to my earlier patch,
"selftests/bpf: Introduce experimental bpf_in_interrupt()"[1], which
demonstrates this approach.

Links:
[1] https://lore.kernel.org/bpf/20250903140438.59517-1-leon.hwang@linux.dev/

Thanks,
Leon

[...]