* linux-next: manual merge of the bpf-next tree with the origin tree
@ 2026-04-14 12:18 Mark Brown
2026-04-14 14:09 ` Alexei Starovoitov
0 siblings, 1 reply; 3+ messages in thread
From: Mark Brown @ 2026-04-14 12:18 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking
Cc: Joel Fernandes, Kumar Kartikeya Dwivedi,
Linux Kernel Mailing List, Linux Next Mailing List,
Paul E. McKenney
[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]
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
*
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the origin tree
2026-04-14 12:18 linux-next: manual merge of the bpf-next tree with the origin tree Mark Brown
@ 2026-04-14 14:09 ` Alexei Starovoitov
2026-04-14 14:38 ` Mark Brown
0 siblings, 1 reply; 3+ messages in thread
From: Alexei Starovoitov @ 2026-04-14 14:09 UTC (permalink / raw)
To: Mark Brown
Cc: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking, Joel Fernandes, Kumar Kartikeya Dwivedi,
Linux Kernel Mailing List, Linux Next Mailing List,
Paul E. McKenney
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?!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the origin tree
2026-04-14 14:09 ` Alexei Starovoitov
@ 2026-04-14 14:38 ` Mark Brown
0 siblings, 0 replies; 3+ messages in thread
From: Mark Brown @ 2026-04-14 14:38 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking, Joel Fernandes, Kumar Kartikeya Dwivedi,
Linux Kernel Mailing List, Linux Next Mailing List,
Paul E. McKenney
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-04-14 14:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-14 12:18 linux-next: manual merge of the bpf-next tree with the origin tree Mark Brown
2026-04-14 14:09 ` Alexei Starovoitov
2026-04-14 14:38 ` Mark Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox