2024-04-23 05:00:06

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: manual merge of the vhost tree with the mm tree

Hi all,

Today's linux-next merge of the vhost tree got a conflict in:

drivers/virtio/virtio_mem.c

between commit:

c22e503ced5b ("fix missing vmalloc.h includes")

from the mm-unstable branch of the mm tree and commit:

4ba509048975 ("virtio-mem: support suspend+resume")

from the vhost tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

--
Cheers,
Stephen Rothwell

diff --cc drivers/virtio/virtio_mem.c
index e8355f55a8f7,6d4dfbc53a66..000000000000
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@@ -21,7 -21,7 +21,8 @@@
#include <linux/bitmap.h>
#include <linux/lockdep.h>
#include <linux/log2.h>
+#include <linux/vmalloc.h>
+ #include <linux/suspend.h>

#include <acpi/acpi_numa.h>


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2024-04-23 08:29:21

by David Hildenbrand

[permalink] [raw]
Subject: Re: linux-next: manual merge of the vhost tree with the mm tree

On 23.04.24 06:59, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the vhost tree got a conflict in:
>
> drivers/virtio/virtio_mem.c
>
> between commit:
>
> c22e503ced5b ("fix missing vmalloc.h includes")
>
> from the mm-unstable branch of the mm tree and commit:
>
> 4ba509048975 ("virtio-mem: support suspend+resume")
>
> from the vhost tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>

Easy header conflict. @MST, @Andrew, do we simply want to take that
virtio-mem patch via the MM tree to get rid of the conflict completely?

--
Cheers,

David / dhildenb


2024-04-23 09:32:16

by Michael S. Tsirkin

[permalink] [raw]
Subject: Re: linux-next: manual merge of the vhost tree with the mm tree

On Tue, Apr 23, 2024 at 10:21:55AM +0200, David Hildenbrand wrote:
> On 23.04.24 06:59, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the vhost tree got a conflict in:
> >
> > drivers/virtio/virtio_mem.c
> >
> > between commit:
> >
> > c22e503ced5b ("fix missing vmalloc.h includes")
> >
> > from the mm-unstable branch of the mm tree and commit:
> >
> > 4ba509048975 ("virtio-mem: support suspend+resume")
> >
> > from the vhost tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
>
> Easy header conflict. @MST, @Andrew, do we simply want to take that
> virtio-mem patch via the MM tree to get rid of the conflict completely?

ok by me:

Acked-by: Michael S. Tsirkin <[email protected]>

Andrew if you pick this let me know pls and I will drop it.

> --
> Cheers,
>
> David / dhildenb


2024-04-23 10:06:17

by David Hildenbrand

[permalink] [raw]
Subject: Re: linux-next: manual merge of the vhost tree with the mm tree

On 23.04.24 11:32, Michael S. Tsirkin wrote:
> On Tue, Apr 23, 2024 at 10:21:55AM +0200, David Hildenbrand wrote:
>> On 23.04.24 06:59, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the vhost tree got a conflict in:
>>>
>>> drivers/virtio/virtio_mem.c
>>>
>>> between commit:
>>>
>>> c22e503ced5b ("fix missing vmalloc.h includes")
>>>
>>> from the mm-unstable branch of the mm tree and commit:
>>>
>>> 4ba509048975 ("virtio-mem: support suspend+resume")
>>>
>>> from the vhost tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary. This
>>> is now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your tree
>>> is submitted for merging. You may also want to consider cooperating
>>> with the maintainer of the conflicting tree to minimise any particularly
>>> complex conflicts.
>>>
>>
>> Easy header conflict. @MST, @Andrew, do we simply want to take that
>> virtio-mem patch via the MM tree to get rid of the conflict completely?
>
> ok by me:
>
> Acked-by: Michael S. Tsirkin <[email protected]>
>
> Andrew if you pick this let me know pls and I will drop it.

@Andrew, the relevant patch is

https://lore.kernel.org/linux-kernel/[email protected]/

I could resend, putting you on CC. Whatever you prefer.

--
Cheers,

David / dhildenb


2024-04-23 12:15:35

by Stephen Rothwell

[permalink] [raw]
Subject: Re: linux-next: manual merge of the vhost tree with the mm tree

Hi all,

On Tue, 23 Apr 2024 10:21:55 +0200 David Hildenbrand <[email protected]> wrote:
>
> Easy header conflict. @MST, @Andrew, do we simply want to take that
> virtio-mem patch via the MM tree to get rid of the conflict
> completely?

And because it is so trivial a conflict, you should just mention it to
Linus when you send the merge requests.

--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2024-04-23 18:19:10

by Andrew Morton

[permalink] [raw]
Subject: Re: linux-next: manual merge of the vhost tree with the mm tree

On Tue, 23 Apr 2024 22:03:17 +1000 Stephen Rothwell <[email protected]> wrote:

> Hi all,
>
> On Tue, 23 Apr 2024 10:21:55 +0200 David Hildenbrand <[email protected]> wrote:
> >
> > Easy header conflict. @MST, @Andrew, do we simply want to take that
> > virtio-mem patch via the MM tree to get rid of the conflict
> > completely?
>
> And because it is so trivial a conflict, you should just mention it to
> Linus when you send the merge requests.

Yes, let's leave things as they are. We have to give Linus *something*
to do ;)