Re: linux-next: duplicate patches in the slab tree

[Vlastimil Babka]

On 9/9/24 10:32, Vlastimil Babka wrote:
> On 9/9/24 10:10, Stephen Rothwell wrote:
>> Hi all,
>> 
>> On Mon, 9 Sep 2024 17:12:20 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>>>
>>> The following commits are also in the vfs-brauner tree as different
>>> commits (but the same patches):
>>> 
>>>   c0390d541128 ("fs: pack struct file")
>>>   ea566e18b4de ("fs: use kmem_cache_create_rcu()")
>>>   d345bd2e9834 ("mm: add kmem_cache_create_rcu()")
>>>   e446f18e98e8 ("mm: remove unused argument from create_cache()")
>>>   0f389adb4b80 ("mm: Removed @freeptr_offset to prevent doc warning")
>>> 
>>> These are commits
>>> 
>>>   f2b8943e64a8 ("fs: pack struct file")
>>>   d1e381aa30cb ("fs: use kmem_cache_create_rcu()")
>>>   ba8108d69e5b ("mm: add kmem_cache_create_rcu()")
>>>   a85ba9858175 ("mm: remove unused argument from create_cache()")
>>>   6e016babce7c ("mm: Removed @freeptr_offset to prevent doc warning")
>>> 
>>> in the vfs-brauner tree.
>>> 
>>> These duplicates are causing unnecessary comflicts ...
>> 
>> So, maybe my merge resolutions were not sufficient, because that then
>> failed to build (powerpc ppc64_defconfig):
>> 
>> mm/slab_common.c: In function 'create_cache':
>> mm/slab_common.c:238:13: error: 'freeptr_offset' undeclared (first use in this function); did you mean 'freeptr_t'?
>>   238 |         if (freeptr_offset != UINT_MAX &&
>>       |             ^~~~~~~~~~~~~~
>>       |             freeptr_t
>> mm/slab_common.c:238:13: note: each undeclared identifier is reported only once for each function it appears in
>> mm/slab_common.c: At top level:
>> mm/slab_common.c:389:20: warning: no previous prototype for 'kmem_cache_create_rcu' [-Wmissing-prototypes]
>>   389 | struct kmem_cache *kmem_cache_create_rcu(const char *name, unsigned int size,
>>       |                    ^~~~~~~~~~~~~~~~~~~~~
>> mm/slab_common.c: In function 'kmem_cache_create_rcu':
>> mm/slab_common.c:393:16: error: implicit declaration of function 'do_kmem_cache_create_usercopy'; did you mean 'kmem_cache_create_usercopy'? [-Wimplicit-function-declaration]
>>   393 |         return do_kmem_cache_create_usercopy(name, size, freeptr_offset, 0,
>>       |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>       |                kmem_cache_create_usercopy
>> mm/slab_common.c:393:16: error: returning 'int' from a function with return type 'struct kmem_cache *' makes pointer from integer without a cast [-Wint-conversion]
>>   393 |         return do_kmem_cache_create_usercopy(name, size, freeptr_offset, 0,
>>       |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   394 |                                              flags | SLAB_TYPESAFE_BY_RCU, 0, 0,
>>       |                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>   395 |                                              NULL);
>>       |                                              ~~~~~
>> 
>> So I used the slab tree from next-20240906 for today in the hope that
>> the duplications will be taken care of and the whole things becomes
>> clearer.
> 
> I'm confused how did that help if slab tree didn't change since 20240906 and
> the commit ids meanwhile changed on the vfs side?

... so it would have to be either slab tree from 20240905 (before it
included the vfs commits), or vfs from 20240906 (before the commits on vfs
side got different id's).

I've noticed no diff (0f389adb4b80 vs 6e016babce7c) nor range-diff (from
v6.11-rc4 as a base) differences in the vfs tree before and after the id's
changed, so it seems that was not done intentionally? I'll wait whether
Christian decides to reset it back, before changing it on the slab side.

I guess if you rolled back vfs side in -next, then it makes more sense to
reset vfs, and if slab side, then slab.