From: Vlastimil Babka <vbabka@suse•cz>
To: Stephen Rothwell <sfr@canb•auug.org.au>,
Christian Brauner <brauner@kernel•org>
Cc: Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>
Subject: Re: linux-next: duplicate patches in the slab tree
Date: Mon, 9 Sep 2024 10:32:06 +0200 [thread overview]
Message-ID: <bde596e3-365b-4fdb-8a03-0a4e40a56246@suse.cz> (raw)
In-Reply-To: <20240909181035.4ffd7434@canb.auug.org.au>
On 9/9/24 10:10, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 9 Sep 2024 17:12:20 +1000 Stephen Rothwell <sfr@canb•auug.org.au> 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?
next prev parent reply other threads:[~2024-09-09 8:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-09 7:12 linux-next: duplicate patches in the slab tree Stephen Rothwell
2024-09-09 7:18 ` Vlastimil Babka
2024-09-09 9:16 ` Christian Brauner
2024-09-09 9:40 ` Vlastimil Babka
2024-09-09 10:13 ` Christian Brauner
2024-09-09 10:35 ` Vlastimil Babka
2024-09-09 10:42 ` Christian Brauner
2024-09-09 11:02 ` Christian Brauner
2024-09-09 11:45 ` Stephen Rothwell
2024-09-09 12:19 ` Christian Brauner
2024-09-09 12:37 ` Christian Brauner
2024-09-09 13:44 ` Stephen Rothwell
2024-09-09 12:09 ` Vlastimil Babka
2024-09-09 12:18 ` Christian Brauner
2024-09-09 13:11 ` Konstantin Ryabitsev
2024-09-09 8:10 ` Stephen Rothwell
2024-09-09 8:32 ` Vlastimil Babka [this message]
2024-09-09 8:49 ` Vlastimil Babka
2024-09-09 9:33 ` Stephen Rothwell
2024-09-09 9:28 ` Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bde596e3-365b-4fdb-8a03-0a4e40a56246@suse.cz \
--to=vbabka@suse$(echo .)cz \
--cc=brauner@kernel$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=sfr@canb$(echo .)auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox