linux-next: duplicate patches in the slab tree

linux-next: duplicate patches in the slab tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

Hi all,

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 ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Vlastimil Babka]

On 9/9/24 09:12, Stephen Rothwell wrote:
> Hi all,
> 
> 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 ...

Thanks,

Christian told me merging the vfs.file branch (a necessary prerequisity for
one series in slab) would be ok as it was stable at that point. What
happened? If I do redo with a new merge, will that stay unchanged until the
merge window?

Vlastimil

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

[Christian Brauner]

On Mon, Sep 09, 2024 at 09:18:57AM GMT, Vlastimil Babka wrote:
> On 9/9/24 09:12, Stephen Rothwell wrote:
> > Hi all,
> > 
> > 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 ...
> 
> Thanks,
> 
> Christian told me merging the vfs.file branch (a necessary prerequisity for
> one series in slab) would be ok as it was stable at that point. What
> happened? If I do redo with a new merge, will that stay unchanged until the
> merge window?

Hm, that's very odd that the IDs changed. The only thing that I did was
b4 trailers -u on the branch to quickly check whether I missed an RvBs
or Acks. But there were none so I assumed that the commit ids wouldn't
change. Let me check and rollback if that was the case.

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

[Vlastimil Babka]

On 9/9/24 11:16, Christian Brauner wrote:
> On Mon, Sep 09, 2024 at 09:18:57AM GMT, Vlastimil Babka wrote:
>> On 9/9/24 09:12, Stephen Rothwell wrote:
>> > Hi all,
>> > 
>> > 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 ...
>> 
>> Thanks,
>> 
>> Christian told me merging the vfs.file branch (a necessary prerequisity for
>> one series in slab) would be ok as it was stable at that point. What
>> happened? If I do redo with a new merge, will that stay unchanged until the
>> merge window?
> 
> Hm, that's very odd that the IDs changed. The only thing that I did was
> b4 trailers -u on the branch to quickly check whether I missed an RvBs
> or Acks. But there were none so I assumed that the commit ids wouldn't

I guess b4 could be smarter and not perform/rollback the history rewrite if
there's nothing to change.
I hope I would have caught such surprise by trying git push without --force
if I assumed there was no rebase and only new patches added on top. But
maybe you had some intended rebase in some of the newer patches there.

> change. Let me check and rollback if that was the case.

Thank!

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

[Christian Brauner]

On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
> On 9/9/24 11:16, Christian Brauner wrote:
> > On Mon, Sep 09, 2024 at 09:18:57AM GMT, Vlastimil Babka wrote:
> >> On 9/9/24 09:12, Stephen Rothwell wrote:
> >> > Hi all,
> >> > 
> >> > 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 ...
> >> 
> >> Thanks,
> >> 
> >> Christian told me merging the vfs.file branch (a necessary prerequisity for
> >> one series in slab) would be ok as it was stable at that point. What
> >> happened? If I do redo with a new merge, will that stay unchanged until the
> >> merge window?
> > 
> > Hm, that's very odd that the IDs changed. The only thing that I did was
> > b4 trailers -u on the branch to quickly check whether I missed an RvBs
> > or Acks. But there were none so I assumed that the commit ids wouldn't
> 
> I guess b4 could be smarter and not perform/rollback the history rewrite if
> there's nothing to change.
> I hope I would have caught such surprise by trying git push without --force
> if I assumed there was no rebase and only new patches added on top. But
> maybe you had some intended rebase in some of the newer patches there.
> 
> > change. Let me check and rollback if that was the case.
> 
> Thank!

No problem. I promised a stable branch so you'll get one. :)

So I rebased vfs.file onto the previous patches and pushed it out.
Note that I've merged an additional series into vfs.file but that should
not matter to you as long as you keep using our shared base.

Note, I also pulled

git pull -S slab slab/for-6.12/kmem_cache_args

into vfs.file.slab for a test and that works fine so commit ids should
be back to their previous state. But please do double-check.

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

[Vlastimil Babka]

On 9/9/24 12:13, Christian Brauner wrote:
> On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
>> 
>> > change. Let me check and rollback if that was the case.
>> 
>> Thank!
> 
> No problem. I promised a stable branch so you'll get one. :)
> 
> So I rebased vfs.file onto the previous patches and pushed it out.
> Note that I've merged an additional series into vfs.file but that should
> not matter to you as long as you keep using our shared base.

> Note, I also pulled
> 
> git pull -S slab slab/for-6.12/kmem_cache_args
> 
> into vfs.file.slab for a test and that works fine so commit ids should
> be back to their previous state. But please do double-check.

It seems I'll be fine indeed as our shared base 0f389adb4b80 is back, but
looks like the top-most merge commit 3a3e007d8946 is wrong as it has
6e016babce7c (the rewrite of 0f389adb4b80) as parent instead, so there are
now duplicated commits in vfs.file itself:

https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.file

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

[Christian Brauner]

On Mon, Sep 09, 2024 at 12:35:37PM GMT, Vlastimil Babka wrote:
> On 9/9/24 12:13, Christian Brauner wrote:
> > On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
> >> 
> >> > change. Let me check and rollback if that was the case.
> >> 
> >> Thank!
> > 
> > No problem. I promised a stable branch so you'll get one. :)
> > 
> > So I rebased vfs.file onto the previous patches and pushed it out.
> > Note that I've merged an additional series into vfs.file but that should
> > not matter to you as long as you keep using our shared base.
> 
> > Note, I also pulled
> > 
> > git pull -S slab slab/for-6.12/kmem_cache_args
> > 
> > into vfs.file.slab for a test and that works fine so commit ids should
> > be back to their previous state. But please do double-check.
> 
> It seems I'll be fine indeed as our shared base 0f389adb4b80 is back, but
> looks like the top-most merge commit 3a3e007d8946 is wrong as it has
> 6e016babce7c (the rewrite of 0f389adb4b80) as parent instead, so there are
> now duplicated commits in vfs.file itself:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.file

Thanks! Ffs, let me go fix that.

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

[Christian Brauner]

On Mon, Sep 09, 2024 at 12:42:53PM GMT, Christian Brauner wrote:
> On Mon, Sep 09, 2024 at 12:35:37PM GMT, Vlastimil Babka wrote:
> > On 9/9/24 12:13, Christian Brauner wrote:
> > > On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
> > >> 
> > >> > change. Let me check and rollback if that was the case.
> > >> 
> > >> Thank!
> > > 
> > > No problem. I promised a stable branch so you'll get one. :)
> > > 
> > > So I rebased vfs.file onto the previous patches and pushed it out.
> > > Note that I've merged an additional series into vfs.file but that should
> > > not matter to you as long as you keep using our shared base.
> > 
> > > Note, I also pulled
> > > 
> > > git pull -S slab slab/for-6.12/kmem_cache_args
> > > 
> > > into vfs.file.slab for a test and that works fine so commit ids should
> > > be back to their previous state. But please do double-check.
> > 
> > It seems I'll be fine indeed as our shared base 0f389adb4b80 is back, but
> > looks like the top-most merge commit 3a3e007d8946 is wrong as it has
> > 6e016babce7c (the rewrite of 0f389adb4b80) as parent instead, so there are
> > now duplicated commits in vfs.file itself:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.file
> 
> Thanks! Ffs, let me go fix that.

Ok, how's it looking now?

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

Hi Christian,

On Mon, 9 Sep 2024 13:02:03 +0200 Christian Brauner <brauner@kernel.org> wrote:
>
> Ok, how's it looking now?

I just fetched your tree.  The top commit (vfs.all branch) is

  a80a1ee241e7 ("Merge branch 'vfs.procfs' into vfs.all Signed-off-by: Christian Brauner <brauner@kernel.org>")

and commits

  f2b8943e64a8 ("fs: pack struct file")
  c0390d541128 ("fs: pack struct file")

are included.  The first of those was in next-20240902 through today,
the second is new.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Christian Brauner]

On Mon, Sep 09, 2024 at 09:45:33PM GMT, Stephen Rothwell wrote:
> Hi Christian,
> 
> On Mon, 9 Sep 2024 13:02:03 +0200 Christian Brauner <brauner@kernel.org> wrote:
> >
> > Ok, how's it looking now?
> 
> I just fetched your tree.  The top commit (vfs.all branch) is
> 
>   a80a1ee241e7 ("Merge branch 'vfs.procfs' into vfs.all Signed-off-by: Christian Brauner <brauner@kernel.org>")
> 
> and commits
> 
>   f2b8943e64a8 ("fs: pack struct file")
>   c0390d541128 ("fs: pack struct file")

Sorry, I just pushed the fixed version now. Thanks for the patience.

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

[Christian Brauner]

On Mon, Sep 09, 2024 at 02:19:20PM GMT, Christian Brauner wrote:
> On Mon, Sep 09, 2024 at 09:45:33PM GMT, Stephen Rothwell wrote:
> > Hi Christian,
> > 
> > On Mon, 9 Sep 2024 13:02:03 +0200 Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > Ok, how's it looking now?
> > 
> > I just fetched your tree.  The top commit (vfs.all branch) is
> > 
> >   a80a1ee241e7 ("Merge branch 'vfs.procfs' into vfs.all Signed-off-by: Christian Brauner <brauner@kernel.org>")
> > 
> > and commits
> > 
> >   f2b8943e64a8 ("fs: pack struct file")
> >   c0390d541128 ("fs: pack struct file")
> 
> Sorry, I just pushed the fixed version now. Thanks for the patience.

Incidentally, is there a simple command to detect duplicate commits?

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

Hi Christian,

On Mon, 9 Sep 2024 14:37:50 +0200 Christian Brauner <brauner@kernel.org> wrote:
>
> Incidentally, is there a simple command to detect duplicate commits?

Have a look at "git cherry"

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Vlastimil Babka]

On 9/9/24 13:02, Christian Brauner wrote:
> On Mon, Sep 09, 2024 at 12:42:53PM GMT, Christian Brauner wrote:
>> On Mon, Sep 09, 2024 at 12:35:37PM GMT, Vlastimil Babka wrote:
>> > On 9/9/24 12:13, Christian Brauner wrote:
>> > > On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
>> > >> 
>> > >> > change. Let me check and rollback if that was the case.
>> > >> 
>> > >> Thank!
>> > > 
>> > > No problem. I promised a stable branch so you'll get one. :)
>> > > 
>> > > So I rebased vfs.file onto the previous patches and pushed it out.
>> > > Note that I've merged an additional series into vfs.file but that should
>> > > not matter to you as long as you keep using our shared base.
>> > 
>> > > Note, I also pulled
>> > > 
>> > > git pull -S slab slab/for-6.12/kmem_cache_args
>> > > 
>> > > into vfs.file.slab for a test and that works fine so commit ids should
>> > > be back to their previous state. But please do double-check.
>> > 
>> > It seems I'll be fine indeed as our shared base 0f389adb4b80 is back, but
>> > looks like the top-most merge commit 3a3e007d8946 is wrong as it has
>> > 6e016babce7c (the rewrite of 0f389adb4b80) as parent instead, so there are
>> > now duplicated commits in vfs.file itself:
>> > 
>> > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.file
>> 
>> Thanks! Ffs, let me go fix that.
> 
> Ok, how's it looking now?

vfs.file seems ok to me now, but vfs.all has merged the older version of it
thus is not ok yet, as Stephen pointed out. Thanks.

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

[Christian Brauner]

On Mon, Sep 09, 2024 at 02:09:14PM GMT, Vlastimil Babka wrote:
> On 9/9/24 13:02, Christian Brauner wrote:
> > On Mon, Sep 09, 2024 at 12:42:53PM GMT, Christian Brauner wrote:
> >> On Mon, Sep 09, 2024 at 12:35:37PM GMT, Vlastimil Babka wrote:
> >> > On 9/9/24 12:13, Christian Brauner wrote:
> >> > > On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
> >> > >> 
> >> > >> > change. Let me check and rollback if that was the case.
> >> > >> 
> >> > >> Thank!
> >> > > 
> >> > > No problem. I promised a stable branch so you'll get one. :)
> >> > > 
> >> > > So I rebased vfs.file onto the previous patches and pushed it out.
> >> > > Note that I've merged an additional series into vfs.file but that should
> >> > > not matter to you as long as you keep using our shared base.
> >> > 
> >> > > Note, I also pulled
> >> > > 
> >> > > git pull -S slab slab/for-6.12/kmem_cache_args
> >> > > 
> >> > > into vfs.file.slab for a test and that works fine so commit ids should
> >> > > be back to their previous state. But please do double-check.
> >> > 
> >> > It seems I'll be fine indeed as our shared base 0f389adb4b80 is back, but
> >> > looks like the top-most merge commit 3a3e007d8946 is wrong as it has
> >> > 6e016babce7c (the rewrite of 0f389adb4b80) as parent instead, so there are
> >> > now duplicated commits in vfs.file itself:
> >> > 
> >> > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.file
> >> 
> >> Thanks! Ffs, let me go fix that.
> > 
> > Ok, how's it looking now?
> 
> vfs.file seems ok to me now, but vfs.all has merged the older version of it
> thus is not ok yet, as Stephen pointed out. Thanks.

Yeah, I hadn't pushed that yet in case something went wrong. Pushed now.

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

[Konstantin Ryabitsev]

On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
> > Hm, that's very odd that the IDs changed. The only thing that I did was
> > b4 trailers -u on the branch to quickly check whether I missed an RvBs
> > or Acks. But there were none so I assumed that the commit ids wouldn't
> 
> I guess b4 could be smarter and not perform/rollback the history rewrite if
> there's nothing to change.

That should be already the case. If there were no updates to commits, then it
should have been a no-op, so I'm pretty sure something else must have
happened.

-K

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

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.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Vlastimil Babka]

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?

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@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?

... 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.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Hi Vlastimil,

On Mon, 9 Sep 2024 10:49:45 +0200 Vlastimil Babka <vbabka@suse.cz> wrote:
>
> ... 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).

You need to remember that my time zone is UTC+1000 :-)

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

The vfs-brauner tree is merged into linux-next earlyish in the morning.
the slab tree late in the afternoon.  My preference is to rollback the
later tree is that works.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3782 bytes --]

Hi Vlastimil,

On Mon, 9 Sep 2024 10:32:06 +0200 Vlastimil Babka <vbabka@suse.cz> wrote:
>
> 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?

$ git grep slab next-20240906:Next/SHA1snext-20240906:Next/SHA1s:slab           2e0abb33823cd3885e6d9118fccf2a027db9b490
$ git diff --stat 2e0abb33823cd3885e6d9118fccf2a027db9b490...slab/slab/for-next 
warning: 2e0abb33823cd3885e6d9118fccf2a027db9b490...slab/slab/for-next: multiple merge bases, using e02147cb703412fa13dd31908c734d7fb2314f55
 drivers/net/tun.c               |   6 +
 drivers/tty/tty_io.c            |   6 +
 fs/fcntl.c                      | 166 +++++++++++++++++-----
 fs/file_table.c                 |  14 +-
 fs/internal.h                   |   1 +
 fs/locks.c                      |   6 +-
 fs/notify/dnotify/dnotify.c     |   6 +-
 include/linux/fs.h              | 102 ++++++++------
 include/linux/kasan.h           |  65 ++++++++-
 include/linux/rcutiny.h         |   5 +
 include/linux/rcutree.h         |   1 +
 include/linux/slab.h            | 163 +++++++++++++++++++---
 io_uring/io_uring.c             |  14 +-
 kernel/rcu/tree.c               | 109 +++++++++++++--
 lib/slub_kunit.c                |  31 +++++
 mm/Kconfig.debug                |  32 +++++
 mm/kasan/common.c               |  64 +++++----
 mm/kasan/kasan_test.c           |  46 +++++++
 mm/slab.h                       |  11 +-
 mm/slab_common.c                | 260 ++++++++++++----------------------
 mm/slub.c                       | 299 ++++++++++++++++++++++++++++------------
 net/core/sock.c                 |   2 +-
 net/ipv4/inet_connection_sock.c |   5 +-
 security/selinux/hooks.c        |   2 +-
 security/smack/smack_lsm.c      |   2 +-
 25 files changed, 1005 insertions(+), 413 deletions(-)
$ git log --oneline 2e0abb33823cd3885e6d9118fccf2a027db9b490..slab/slab/for-next 
66dcd51a4503 (slab/slab/for-next) Merge branch 'slab/for-6.12/kmem_cache_args' into slab/for-next
fa9057f66dc8 Merge branch 'slab/for-6.12/rcu_barriers' into slab/for-next
8f88d16ae7c4 io_uring: port to struct kmem_cache_args
0745de59907f slab: make __kmem_cache_create() static inline
c97f071a3e39 slab: make kmem_cache_create_usercopy() static inline
6d5110520e00 slab: remove kmem_cache_create_rcu()
212a84da3190 file: port to struct kmem_cache_args
272d25721a77 slab: create kmem_cache_create() compatibility layer
7b8e2fe0c4b3 slab: port KMEM_CACHE_USERCOPY() to struct kmem_cache_args
1f4fcd6cfa1c slab: port KMEM_CACHE() to struct kmem_cache_args
dda9e30e63eb slab: remove rcu_freeptr_offset from struct kmem_cache
45bbb06b3ace slab: pass struct kmem_cache_args to do_kmem_cache_create()
d2ac7d61ed73 slab: pull kmem_cache_open() into do_kmem_cache_create()
2b7491007d1f slab: pass struct kmem_cache_args to create_cache()
be9b2ec72e53 slab: port kmem_cache_create_usercopy() to struct kmem_cache_args
f6ee8439fdad slab: port kmem_cache_create_rcu() to struct kmem_cache_args
e8ccc4307bb0 slab: port kmem_cache_create() to struct kmem_cache_args
95c65689ce1f slab: add struct kmem_cache_args
2a51e14ca2cc memcg: add charging of already allocated slab objects
432e6080ec7d slab: s/__kmem_cache_create/do_kmem_cache_create/g
01cc2238ba4a Merge branch 'vfs.file' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs into slab/for-6.12/kmem_cache_args
0f389adb4b80 mm: Removed @freeptr_offset to prevent doc warning
dfdc8d2565e8 Merge patch series "fs,mm: add kmem_cache_create_rcu()"
ea566e18b4de fs: use kmem_cache_create_rcu()
d345bd2e9834 mm: add kmem_cache_create_rcu()
e446f18e98e8 mm: remove unused argument from create_cache()
c0390d541128 fs: pack struct file

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]