Hi all,

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

  include/linux/rcupdate.h

between commit:

  ad6ef775cbeff ("rcu-tasks: Document that RCU Tasks Trace grace periods now imply RCU grace periods")

from the origin tree and commit:

  57b23c0f612dc ("bpf: Retire rcu_trace_implies_rcu_gp()")

from the bpf-next 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 --combined include/linux/rcupdate.h
index 18a85c30fd4f3,bfa765132de85..0000000000000
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@@ -205,15 -205,6 +205,6 @@@ static inline void exit_tasks_rcu_start
  static inline void exit_tasks_rcu_finish(void) { }
  #endif /* #else #ifdef CONFIG_TASKS_RCU_GENERIC */
  
- /**
-  * rcu_trace_implies_rcu_gp - does an RCU Tasks Trace grace period imply an RCU grace period?
-  *
-  * Now that RCU Tasks Trace is implemented in terms of SRCU-fast, a
-  * call to synchronize_rcu_tasks_trace() is guaranteed to imply at least
-  * one call to synchronize_rcu().
-  */
- static inline bool rcu_trace_implies_rcu_gp(void) { return true; }
- 
  /**
   * cond_resched_tasks_rcu_qs - Report potential quiescent states to RCU
   *

On Tue, Apr 14, 2026 at 5:18 AM Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
>   include/linux/rcupdate.h
>
> between commit:
>
>   ad6ef775cbeff ("rcu-tasks: Document that RCU Tasks Trace grace periods now imply RCU grace periods")
>
> from the origin tree and commit:
>
>   57b23c0f612dc ("bpf: Retire rcu_trace_implies_rcu_gp()")
>
> from the bpf-next 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 --combined include/linux/rcupdate.h
> index 18a85c30fd4f3,bfa765132de85..0000000000000
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@@ -205,15 -205,6 +205,6 @@@ static inline void exit_tasks_rcu_start
>   static inline void exit_tasks_rcu_finish(void) { }
>   #endif /* #else #ifdef CONFIG_TASKS_RCU_GENERIC */
>
> - /**
> -  * rcu_trace_implies_rcu_gp - does an RCU Tasks Trace grace period imply an RCU grace period?
> -  *
> -  * Now that RCU Tasks Trace is implemented in terms of SRCU-fast, a
> -  * call to synchronize_rcu_tasks_trace() is guaranteed to imply at least
> -  * one call to synchronize_rcu().
> -  */
> - static inline bool rcu_trace_implies_rcu_gp(void) { return true; }
> -

Right. I mentioned it in my bpf-next PR.

But how come you're saying it was discovered "today" ?

Paul's commit ad6ef775cbeff was committed to rcu tree on Mar 30,
while Kumar's 57b23c0f612dc was committed to bpf-next on Apr 7.

"today" is April 14.

My only explanation is that rcu tree was not in linux-next until today?!

On Tue, Apr 14, 2026 at 07:09:44AM -0700, Alexei Starovoitov wrote:

> But how come you're saying it was discovered "today" ?

> Paul's commit ad6ef775cbeff was committed to rcu tree on Mar 30,
> while Kumar's 57b23c0f612dc was committed to bpf-next on Apr 7.

> "today" is April 14.

> My only explanation is that rcu tree was not in linux-next until today?!

We're in the merge window, this means things get sent to Linus and end
up in his tree.  This in turn means that they are seen in different
orders, and sometimes depending on context in different forms.  -next
is merged sequentially, it's not an octopus merge of all the trees at
once.  Some variation of this will likely have been seen before, but not
this exact combination.