Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  kernel/trace/bpf_trace.c

between commit:

  93f0d09697613 ("bpf: move recursion detection logic to helpers")

from the bpf-next tree and commit:

  f7d327654b886 ("bpf: Have __bpf_trace_run() use rcu_read_lock_dont_migrate()")

from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc kernel/trace/bpf_trace.c
index f7baeb8278cac,abbf0177ad20b..0000000000000
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@@ -2076,8 -2062,8 +2076,8 @@@ void __bpf_trace_run(struct bpf_raw_tp_
  	struct bpf_run_ctx *old_run_ctx;
  	struct bpf_trace_run_ctx run_ctx;
  
- 	cant_sleep();
+ 	rcu_read_lock_dont_migrate();
 -	if (unlikely(this_cpu_inc_return(*(prog->active)) != 1)) {
 +	if (unlikely(!bpf_prog_get_recursion_context(prog))) {
  		bpf_prog_inc_misses_counter(prog);
  		goto out;
  	}
@@@ -2090,8 -2075,8 +2089,8 @@@
  
  	bpf_reset_run_ctx(old_run_ctx);
  out:
 -	this_cpu_dec(*(prog->active));
 +	bpf_prog_put_recursion_context(prog);
+ 	rcu_read_unlock_migrate();
  }
  
  #define UNPACK(...)			__VA_ARGS__

On Mon, 2 Feb 2026 14:30:14 +0000
Mark Brown <broonie@kernel.org> wrote:

> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Mark, the fix looks good to me. The conflict was caused by ftrace
doing a small change that was recommended by Alexei so I hope this isn't a
complex conflict ;-)

-- Steve

On Mon, Feb 2, 2026 at 8:19 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 2 Feb 2026 14:30:14 +0000
> Mark Brown <broonie@kernel.org> wrote:
>
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> Thanks Mark, the fix looks good to me. The conflict was caused by ftrace
> doing a small change that was recommended by Alexei so I hope this isn't a
> complex conflict ;-)

yep.
Conflict resolution is correct.

I wonder whether we should take the whole srcu_fast in tracepoints
patch set into bpf-next to avoid this conflict ?
Probably not worth it in the last week before the merge window.
Just a thought.

On Mon, 2 Feb 2026 08:42:55 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> I wonder whether we should take the whole srcu_fast in tracepoints
> patch set into bpf-next to avoid this conflict ?
> Probably not worth it in the last week before the merge window.
> Just a thought.

It's already in next where it would require a revert to get rid of.

There's just one patch that touches the bpf code, so it still makes more
sense to keep it in the tracing tree.

-- Steve