All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiri Olsa" <jolsa@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 7/9] bpf: Factor callchain_finalize function from __bpf_get_stack
Date: Mon, 20 Jul 2026 09:08:10 +0000	[thread overview]
Message-ID: <20260720090811.1651B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720085351.655075-8-jolsa@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Sleepable BPF programs calling bpf_get_stack() or bpf_get_task_stack() can corrupt per-CPU perf callchain buffers and trigger preemption warnings.
--

--- Patch [7]: [PATCH bpf-next 7/9] bpf: Factor callchain_finalize function from __bpf_get_stack ---
commit a181c39a42a0e8c840b9a2a09b02e1efa512170b
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Factor callchain_finalize function from __bpf_get_stack
    
The new callchain_finalize function calls the build-id retrieval
(if needed) and zeroes the buffer.

> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index b990643f25cd8..eea7b781300ca 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
[ ... ]
> @@ -827,18 +840,12 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
>  	}
>  
>  	trace_nr = callchain_store(trace, buf, size, elem_size, flags);
> -	copy_len = trace_nr * elem_size;
>  
>  	/* trace should not be dereferenced after this point */
>  	if (may_fault)
>  		rcu_read_unlock();

[Severity: High]
This is a pre-existing issue, but can sleepable BPF programs calling this
function corrupt per-CPU perf callchain buffers and trigger preemption
warnings?

When may_fault is true (such as from bpf_get_stack_sleepable or
bpf_get_task_stack_sleepable), this code relies on rcu_read_lock() earlier
in the function. However, on PREEMPT_RCU kernels, rcu_read_lock() does not
disable preemption.

The earlier call to get_perf_callchain() eventually reaches
get_callchain_entry(), which relies on smp_processor_id() and requires
preemption to be explicitly disabled:

kernel/events/callchain.c:get_callchain_entry() {
    ...
    cpu = smp_processor_id();
    return (((void *)entries->cpu_entries[cpu]) +
            (*rctx * perf_callchain_entry__sizeof()));
}

Since preemption is not disabled during this sequence, can the task be
preempted during or after fetching the per-CPU buffer, allowing another BPF
program on the same CPU to overwrite the buffer before it is copied by
callchain_store()?

> -	if (user_build_id)
> -		stack_map_get_build_id_offset(buf, trace_nr, user, may_fault);
> -
> -	if (size > copy_len)
> -		memset(buf + copy_len, 0, size - copy_len);
> -	return copy_len;
> +	return callchain_finalize(buf, size, trace_nr, elem_size, user_build_id, user, may_fault);
>  
>  err_fault:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720085351.655075-1-jolsa@kernel.org?part=7

  reply	other threads:[~2026-07-20  9:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20  8:53 [PATCH bpf-next 0/9] bpf: Disable preemption in stack map code Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 1/9] bpf: Factor stackid_init function from __bpf_get_stackid Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 2/9] bpf: Factor stackid_fastpath " Jiri Olsa
2026-07-20  9:09   ` sashiko-bot
2026-07-20 20:31     ` Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 3/9] bpf: Factor stackid_new_bucket " Jiri Olsa
2026-07-20  9:01   ` sashiko-bot
2026-07-20 20:31     ` Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 4/9] bpf: Use stack id functions instead of __bpf_get_stackid Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 5/9] bpf: Disable preemption in bpf_get_stackid Jiri Olsa
2026-07-20  9:04   ` sashiko-bot
2026-07-20 20:31     ` Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 6/9] bpf: Factor callchain_store function from __bpf_get_stack Jiri Olsa
2026-07-20  9:07   ` sashiko-bot
2026-07-20 20:31     ` Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 7/9] bpf: Factor callchain_finalize " Jiri Olsa
2026-07-20  9:08   ` sashiko-bot [this message]
2026-07-20 20:31     ` Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 8/9] bpf: Remove trace_in argument " Jiri Olsa
2026-07-20  9:09   ` sashiko-bot
2026-07-20 20:31     ` Jiri Olsa
2026-07-20  8:53 ` [PATCH bpf-next 9/9] bpf: Disable preemption in __bpf_get_stack Jiri Olsa
2026-07-20  9:18   ` sashiko-bot

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=20260720090811.1651B1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jolsa@kernel.org \
    --cc=sashiko-reviews@lists.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.