Re: linux-next: manual merge of the slab tree with the rcu tree

On Tue, Aug 4, 2026 at 10:44 AM Vlastimil Babka (SUSE)
<[email protected]> wrote:
>
> With Gary's suggestion [1] CONFIG_KVFREE_RCU_BATCHED will go out of the
> picture completely anyway. What remains is an unconditional change of the
> parameter. Can it be "resolved in advance" or only in the merge commit?
>
> https://lore.kernel.org/all/[email protected]/

Hmm... I am not sure I follow why we are trying to resolve these
things in advance.

Semantic conflicts can be painful because they can be easily forgotten
about, but as long as it is warned about when doing the pull (and
making sure linux-next has the wanted resolution), it should be fine
-- branches can still be independent.

Now, if for some reason one really wants to solve the conflict on one
of the sides, then one can do a merge commit and justify it well. The
diffs proposed here seem small, so I am not sure why we would want
that. Usually what Linus prefers is to give him that merge in another
branch for reference, rather than sending the merge itself.

What I would avoid is adding a workaround that requires knowing about
the "future" (like depending on an unknown `cfg`, assuming it was
unknown). Sometimes we do that (e.g. when building features), but it
isn't really the case here...

Cheers,
Miguel