Re: [PATCH RFC net-next 2/9] bpf: add bpf_ktime_get_real_ns() kfunc

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: bpf_ktime_get_real_ns() causes hard lockup in NMI context
--

commit 5767d1a435f8b04a603eb9c7fef3df289f64be7b
Author: Jason Xing <kerneljasonxing@gmail.com>

bpf: add bpf_ktime_get_real_ns() kfunc

Introduce a new BPF kfunc bpf_ktime_get_real_ns() that returns the
current CLOCK_REALTIME time.

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index b3cc5c8fc8756..7a0db620a2730 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2335,6 +2335,11 @@ void bpf_rb_root_free(const struct btf_field *field, void *rb_root,
>  
>  __bpf_kfunc_start_defs();
>  
> +__bpf_kfunc u64 bpf_ktime_get_real_ns(void)
> +{
> +	return ktime_to_ns(ktime_get_real());

[Severity: High]
Can this cause a hard lockup if called from NMI context?

The ktime_get_real() function uses read_seqcount_begin(&tk_core.seq)
internally to read the time. If a BPF program running in NMI context (such as
a perf event or kprobe) calls bpf_ktime_get_real_ns() while the CPU happened
to interrupt a timekeeper update like do_settimeofday64, the seqcount will be
odd. The reader will execute a busy-wait loop indefinitely because the
preempted writer can never complete.

Could this be made NMI-safe by using the latch-based fast timekeeper API
ktime_get_real_fast_ns(), analogous to how bpf_ktime_get_ns() uses
ktime_get_mono_fast_ns()?

> +}
> +
>  /**
>   * bpf_obj_new() - allocate an object described by program BTF
>   * @local_type_id__k: type ID in program BTF

[ ... ]

> @@ -4972,6 +4977,7 @@ BTF_ID_FLAGS(func, bpf_task_work_schedule_resume, KF_IMPLICIT_ARGS)
>  BTF_ID_FLAGS(func, bpf_dynptr_from_file)
>  BTF_ID_FLAGS(func, bpf_dynptr_file_discard, KF_RELEASE)
>  BTF_ID_FLAGS(func, bpf_timer_cancel_async)
> +BTF_ID_FLAGS(func, bpf_ktime_get_real_ns)

[Severity: High]
Does registering this kfunc in the common_btf_ids set (BPF_PROG_TYPE_UNSPEC)
expose it to NMI-context BPF programs, leading to the potential lockup
described above?

>  BTF_KFUNCS_END(common_btf_ids)
>  
>  static const struct btf_kfunc_id_set common_kfunc_set = {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260919143732.11772-1-kerneljasonxing@gmail.com?part=2