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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 8/4/26 12:01, Miguel Ojeda wrote:
> On Tue, Aug 4, 2026 at 10:44 AM Vlastimil Babka (SUSE)
> <vbabka@kernel.org> 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/11a8bf75-8fc1-4d32-a350-6bf8156dd8ab@kernel.org/
> 
> 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.

Alright, let's leave it to the merge commit then. The slab side was updated
to allow the simple merge commit resolution Gary suggested. It's better than
relying on the #define in any case.

https://lore.kernel.org/all/7189ebb5-ae48-4466-9055-1ab1b0b5ef7c@kernel.org/

> 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