linux-next: build failure after merge of the xen-two tree

linux-next: build failure after merge of the xen-two tree

[Stephen Rothwell]

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

Hi Konrad,

After merging the xen-two tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/xen/xen-acpi-memhotplug.c: In function 'acpi_memory_get_device':
drivers/xen/xen-acpi-memhotplug.c:191:2: error: implicit declaration of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
drivers/xen/xen-acpi-memhotplug.c: At top level:
drivers/xen/xen-acpi-memhotplug.c:417:3: warning: initialization from incompatible pointer type [enabled by default]
drivers/xen/xen-acpi-memhotplug.c:417:3: warning: (near initialization for 'xen_acpi_memory_device_driver.ops.remove') [enabled by default]

Caused by commit 259f201cb7ea ("xen/acpi: ACPI memory hotplug").

drivers/xen/xen-acpi-cpuhotplug.c: In function 'acpi_processor_device_add':
drivers/xen/xen-acpi-cpuhotplug.c:254:2: error: implicit declaration of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
drivers/xen/xen-acpi-cpuhotplug.c: At top level:
drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: initialization from incompatible pointer type [enabled by default]
drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: (near initialization for 'xen_acpi_processor_driver.ops.remove') [enabled by default]

Caused by commit 181232c249f0 ("xen/acpi: ACPI cpu hotplug").

These commits interacted with commits 636458de36f1 ("ACPI: Remove the
arguments of acpi_bus_add() that are not used"), 0cd6ac52b333 ("ACPI:
Make acpi_bus_scan() and acpi_bus_add() take only one argument") and
b8bd759acd05 ("ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan()
instead") from the pm tree.

I have added this merge fix patch and can carry it as necessary (I did
*not* fix the warnings above):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 15 Feb 2013 15:37:27 +1100
Subject: [PATCH] xen/acpi: fix up for apci_bus_add api change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/xen/xen-acpi-cpuhotplug.c | 2 +-
 drivers/xen/xen-acpi-memhotplug.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-acpi-cpuhotplug.c b/drivers/xen/xen-acpi-cpuhotplug.c
index 9eefbb0..0db4722 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -251,7 +251,7 @@ int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device)
 	if (acpi_bus_get_device(phandle, &pdev))
 		return -ENODEV;
 
-	if (acpi_bus_add(device, pdev, handle, ACPI_BUS_TYPE_PROCESSOR))
+	if (acpi_bus_scan(handle))
 		return -ENODEV;
 
 	return 0;
diff --git a/drivers/xen/xen-acpi-memhotplug.c b/drivers/xen/xen-acpi-memhotplug.c
index 678680c..164287b 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -188,7 +188,7 @@ acpi_memory_get_device(acpi_handle handle,
 	 * Now add the notified device.  This creates the acpi_device
 	 * and invokes .add function
 	 */
-	result = acpi_bus_add(&device, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
+	result = acpi_bus_scan(handle);
 	if (result) {
 		pr_warn(PREFIX "Cannot add acpi bus\n");
 		return -EINVAL;
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the xen-two tree

[Konrad Rzeszutek Wilk]

On Fri, Feb 15, 2013 at 03:45:51PM +1100, Stephen Rothwell wrote:
> Hi Konrad,
> 
> After merging the xen-two tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

Good morning!
> 
> drivers/xen/xen-acpi-memhotplug.c: In function 'acpi_memory_get_device':
> drivers/xen/xen-acpi-memhotplug.c:191:2: error: implicit declaration of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
> drivers/xen/xen-acpi-memhotplug.c: At top level:
> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: initialization from incompatible pointer type [enabled by default]
> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: (near initialization for 'xen_acpi_memory_device_driver.ops.remove') [enabled by default]
> 
> Caused by commit 259f201cb7ea ("xen/acpi: ACPI memory hotplug").
> 
> drivers/xen/xen-acpi-cpuhotplug.c: In function 'acpi_processor_device_add':
> drivers/xen/xen-acpi-cpuhotplug.c:254:2: error: implicit declaration of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
> drivers/xen/xen-acpi-cpuhotplug.c: At top level:
> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: initialization from incompatible pointer type [enabled by default]
> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: (near initialization for 'xen_acpi_processor_driver.ops.remove') [enabled by default]
> 
> Caused by commit 181232c249f0 ("xen/acpi: ACPI cpu hotplug").

Grrrreat! Jinsong, can you please fix that ? A patch on top of the #linux-next
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

> 
> These commits interacted with commits 636458de36f1 ("ACPI: Remove the
> arguments of acpi_bus_add() that are not used"), 0cd6ac52b333 ("ACPI:
> Make acpi_bus_scan() and acpi_bus_add() take only one argument") and
> b8bd759acd05 ("ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan()
> instead") from the pm tree.
> 
> I have added this merge fix patch and can carry it as necessary (I did
> *not* fix the warnings above):

<nods>
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 15 Feb 2013 15:37:27 +1100
> Subject: [PATCH] xen/acpi: fix up for apci_bus_add api change

Thank you. I keep on forgetting - but would it be OK for me to take this
patch in my tree? Or should I not since this is a new functionality that
Rafael is going to introduce in v3.9?

And if so, perhaps I should tack it on in my tree, once Rafael does a git
pull to Linus? Or just point Linus to this git commit?

BTW, I really appreciate the work you are doing to keep sync of different
trees and bubbling this up before the merge window opens.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/xen/xen-acpi-cpuhotplug.c | 2 +-
>  drivers/xen/xen-acpi-memhotplug.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-acpi-cpuhotplug.c b/drivers/xen/xen-acpi-cpuhotplug.c
> index 9eefbb0..0db4722 100644
> --- a/drivers/xen/xen-acpi-cpuhotplug.c
> +++ b/drivers/xen/xen-acpi-cpuhotplug.c
> @@ -251,7 +251,7 @@ int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device)
>  	if (acpi_bus_get_device(phandle, &pdev))
>  		return -ENODEV;
>  
> -	if (acpi_bus_add(device, pdev, handle, ACPI_BUS_TYPE_PROCESSOR))
> +	if (acpi_bus_scan(handle))
>  		return -ENODEV;
>  
>  	return 0;
> diff --git a/drivers/xen/xen-acpi-memhotplug.c b/drivers/xen/xen-acpi-memhotplug.c
> index 678680c..164287b 100644
> --- a/drivers/xen/xen-acpi-memhotplug.c
> +++ b/drivers/xen/xen-acpi-memhotplug.c
> @@ -188,7 +188,7 @@ acpi_memory_get_device(acpi_handle handle,
>  	 * Now add the notified device.  This creates the acpi_device
>  	 * and invokes .add function
>  	 */
> -	result = acpi_bus_add(&device, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
> +	result = acpi_bus_scan(handle);
>  	if (result) {
>  		pr_warn(PREFIX "Cannot add acpi bus\n");
>  		return -EINVAL;
> -- 
> 1.8.1
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

Re: linux-next: build failure after merge of the xen-two tree

[Stephen Rothwell]

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

Hi Konrad,

On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
> Thank you. I keep on forgetting - but would it be OK for me to take this
> patch in my tree? Or should I not since this is a new functionality that
> Rafael is going to introduce in v3.9?

It is an API change in the pm tree that is not yet in Linus' tree.

> And if so, perhaps I should tack it on in my tree, once Rafael does a git
> pull to Linus? Or just point Linus to this git commit?

You should point Linus at this patch if the pm tree is merged first, or
Rafael should do the same if the reverse happens.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the xen-two tree

[Rafael J. Wysocki]

On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
> Hi Konrad,
> 
> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >
> > Thank you. I keep on forgetting - but would it be OK for me to take this
> > patch in my tree? Or should I not since this is a new functionality that
> > Rafael is going to introduce in v3.9?
> 
> It is an API change in the pm tree that is not yet in Linus' tree.
> 
> > And if so, perhaps I should tack it on in my tree, once Rafael does a git
> > pull to Linus? Or just point Linus to this git commit?
> 
> You should point Linus at this patch if the pm tree is merged first, or
> Rafael should do the same if the reverse happens.

Alternatively, Konrad can pull the acpi-scan branch containing the changes
in question from my tree into his tree and rebase the new material on top
of that.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: linux-next: build failure after merge of the xen-two tree

[Stephen Rothwell]

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

Hi Rafael,

On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
> > 
> > On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > >
> > > Thank you. I keep on forgetting - but would it be OK for me to take this
> > > patch in my tree? Or should I not since this is a new functionality that
> > > Rafael is going to introduce in v3.9?
> > 
> > It is an API change in the pm tree that is not yet in Linus' tree.
> > 
> > > And if so, perhaps I should tack it on in my tree, once Rafael does a git
> > > pull to Linus? Or just point Linus to this git commit?
> > 
> > You should point Linus at this patch if the pm tree is merged first, or
> > Rafael should do the same if the reverse happens.
> 
> Alternatively, Konrad can pull the acpi-scan branch containing the changes
> in question from my tree into his tree and rebase the new material on top
> of that.

Or pull the acpi-scan branch into his tree and use my conflict resolution
in the resulting merge thus requiring no rebasing.  However, Linus likes
to see such interactions, so it can be left up to when the latter of the
two tress is merged by Linus.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

RE: linux-next: build failure after merge of the xen-two tree

[Liu, Jinsong]

Stephen Rothwell wrote:
> Hi Rafael,
> 
> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
> wrote: 
>> 
>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
>>> 
>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
>>> <konrad.wilk@oracle.com> wrote: 
>>>> 
>>>> Thank you. I keep on forgetting - but would it be OK for me to
>>>> take this patch in my tree? Or should I not since this is a new
>>>> functionality that Rafael is going to introduce in v3.9?
>>> 
>>> It is an API change in the pm tree that is not yet in Linus' tree.
>>> 
>>>> And if so, perhaps I should tack it on in my tree, once Rafael
>>>> does a git pull to Linus? Or just point Linus to this git commit?
>>> 
>>> You should point Linus at this patch if the pm tree is merged
>>> first, or 
>>> Rafael should do the same if the reverse happens.
>> 
>> Alternatively, Konrad can pull the acpi-scan branch containing the
>> changes in question from my tree into his tree and rebase the new
>> material on top of that.
> 
> Or pull the acpi-scan branch into his tree and use my conflict
> resolution in the resulting merge thus requiring no rebasing. 
> However, Linus likes to see such interactions, so it can be left up
> to when the latter of the two tress is merged by Linus.

Per my understanding, currently in git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git, it has included
1). 636458de36f1, 0cd6ac52b333, b8bd759acd05: 	from pm tree (Rafael), drop acpi_bus_add, update argument of acpi_bus_scan
2). 259f201cb7ea, 181232c249f0:			from xen tree (Jinsong), use acpi_bus_add
3). 36bd3c64bfe2					Stephen fix confliction of 1) and 2)
Currently these are only some compiling warning left, so the only thing need to do is to add my patch to fix compile warning (just sent out minutes ago) to the top of git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ?


Thanks,
Jinsong

Re: linux-next: build failure after merge of the xen-two tree

[Rafael J. Wysocki]

On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote:
> Hi Rafael,

Hi,

> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> >
> > On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
> > > 
> > > On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > >
> > > > Thank you. I keep on forgetting - but would it be OK for me to take this
> > > > patch in my tree? Or should I not since this is a new functionality that
> > > > Rafael is going to introduce in v3.9?
> > > 
> > > It is an API change in the pm tree that is not yet in Linus' tree.
> > > 
> > > > And if so, perhaps I should tack it on in my tree, once Rafael does a git
> > > > pull to Linus? Or just point Linus to this git commit?
> > > 
> > > You should point Linus at this patch if the pm tree is merged first, or
> > > Rafael should do the same if the reverse happens.
> > 
> > Alternatively, Konrad can pull the acpi-scan branch containing the changes
> > in question from my tree into his tree and rebase the new material on top
> > of that.
> 
> Or pull the acpi-scan branch into his tree and use my conflict resolution
> in the resulting merge thus requiring no rebasing.  However, Linus likes
> to see such interactions, so it can be left up to when the latter of the
> two tress is merged by Linus.

Well, I'm afraid this won't be sufficient this time, because of this commit in
my tree (which is not on the acpi-scan branch):

commit 3757b94802fb65d8f696597a74053cf21738da0b
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Feb 13 14:36:47 2013 +0100

    ACPI / hotplug: Fix concurrency issues and memory leaks

after which acpi_bus_scan() and acpi_bus_trim() have to be run under
acpi_scan_lock (new in my tree as well).

Moreover, I think that the introduction of ACPI-based CPU hotplug into Xen
and this point would be premature, because we need to rework the original
ACPI-based CPU hotplug and quite frankly it shouldn't call acpi_bus_scan()
directly at all.

Konrad?

Thanks,
Rafael

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

RE: linux-next: build failure after merge of the xen-two tree

[Liu, Jinsong]

Rafael J. Wysocki wrote:
> On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote:
>> Hi Rafael,
> 
> Hi,
> 
>> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
>> wrote: 
>>> 
>>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
>>>> 
>>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
>>>> <konrad.wilk@oracle.com> wrote: 
>>>>> 
>>>>> Thank you. I keep on forgetting - but would it be OK for me to
>>>>> take this patch in my tree? Or should I not since this is a new
>>>>> functionality that Rafael is going to introduce in v3.9?
>>>> 
>>>> It is an API change in the pm tree that is not yet in Linus' tree.
>>>> 
>>>>> And if so, perhaps I should tack it on in my tree, once Rafael
>>>>> does a git pull to Linus? Or just point Linus to this git commit?
>>>> 
>>>> You should point Linus at this patch if the pm tree is merged
>>>> first, or 
>>>> Rafael should do the same if the reverse happens.
>>> 
>>> Alternatively, Konrad can pull the acpi-scan branch containing the
>>> changes in question from my tree into his tree and rebase the new
>>> material on top of that.
>> 
>> Or pull the acpi-scan branch into his tree and use my conflict
>> resolution in the resulting merge thus requiring no rebasing. 
>> However, Linus likes to see such interactions, so it can be left up
>> to when the latter of the two tress is merged by Linus.
> 
> Well, I'm afraid this won't be sufficient this time, because of this
> commit in my tree (which is not on the acpi-scan branch):
> 
> commit 3757b94802fb65d8f696597a74053cf21738da0b
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Wed Feb 13 14:36:47 2013 +0100
> 
>     ACPI / hotplug: Fix concurrency issues and memory leaks
> 
> after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> acpi_scan_lock (new in my tree as well).

Yes, we noticed that and only need minor updates at xen side, will send out 2 xen patches later accordingly, for cleanup and adding lock.

Thanks,
Jinsong

> 
> Moreover, I think that the introduction of ACPI-based CPU hotplug
> into Xen and this point would be premature, because we need to rework
> the original ACPI-based CPU hotplug and quite frankly it shouldn't
> call acpi_bus_scan() directly at all.
> 
> Konrad?
> 
> Thanks,
> Rafael

Re: linux-next: build failure after merge of the xen-two tree

[Rafael J. Wysocki]

On Sunday, February 17, 2013 07:31:37 AM Liu, Jinsong wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote:
> >> Hi Rafael,
> > 
> > Hi,
> > 
> >> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@sisk.pl>
> >> wrote: 
> >>> 
> >>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote:
> >>>> 
> >>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk
> >>>> <konrad.wilk@oracle.com> wrote: 
> >>>>> 
> >>>>> Thank you. I keep on forgetting - but would it be OK for me to
> >>>>> take this patch in my tree? Or should I not since this is a new
> >>>>> functionality that Rafael is going to introduce in v3.9?
> >>>> 
> >>>> It is an API change in the pm tree that is not yet in Linus' tree.
> >>>> 
> >>>>> And if so, perhaps I should tack it on in my tree, once Rafael
> >>>>> does a git pull to Linus? Or just point Linus to this git commit?
> >>>> 
> >>>> You should point Linus at this patch if the pm tree is merged
> >>>> first, or 
> >>>> Rafael should do the same if the reverse happens.
> >>> 
> >>> Alternatively, Konrad can pull the acpi-scan branch containing the
> >>> changes in question from my tree into his tree and rebase the new
> >>> material on top of that.
> >> 
> >> Or pull the acpi-scan branch into his tree and use my conflict
> >> resolution in the resulting merge thus requiring no rebasing. 
> >> However, Linus likes to see such interactions, so it can be left up
> >> to when the latter of the two tress is merged by Linus.
> > 
> > Well, I'm afraid this won't be sufficient this time, because of this
> > commit in my tree (which is not on the acpi-scan branch):
> > 
> > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Date:   Wed Feb 13 14:36:47 2013 +0100
> > 
> >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > 
> > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > acpi_scan_lock (new in my tree as well).
> 
> Yes, we noticed that and only need minor updates at xen side, will send out
> 2 xen patches later accordingly, for cleanup and adding lock.

Thanks, but those new changes will only make sense after merging the Xen tree
with the PM tree.  Why don't we queue them up for merging later after both
the Xen and PM trees have been pulled from?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: linux-next: build failure after merge of the xen-two tree

[Konrad Rzeszutek Wilk]

> > > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > Date:   Wed Feb 13 14:36:47 2013 +0100
> > > 
> > >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > > 
> > > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > > acpi_scan_lock (new in my tree as well).
> > 
> > Yes, we noticed that and only need minor updates at xen side, will send out
> > 2 xen patches later accordingly, for cleanup and adding lock.
> 
> Thanks, but those new changes will only make sense after merging the Xen tree
> with the PM tree.  Why don't we queue them up for merging later after both
> the Xen and PM trees have been pulled from?

OK, I've created a branch (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
that has your branch and my branch - along with the fix from Stephan and then
the three updates from Jinsong. Jinsong, please check that I've got all the
right patches. I will rebase it once Linus has merged both of the Xen and PM trees.

Re: linux-next: build failure after merge of the xen-two tree

[Rafael J. Wysocki]

On Wednesday, February 20, 2013 03:49:41 PM Konrad Rzeszutek Wilk wrote:
> > > > commit 3757b94802fb65d8f696597a74053cf21738da0b
> > > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > Date:   Wed Feb 13 14:36:47 2013 +0100
> > > > 
> > > >     ACPI / hotplug: Fix concurrency issues and memory leaks
> > > > 
> > > > after which acpi_bus_scan() and acpi_bus_trim() have to be run under
> > > > acpi_scan_lock (new in my tree as well).
> > > 
> > > Yes, we noticed that and only need minor updates at xen side, will send out
> > > 2 xen patches later accordingly, for cleanup and adding lock.
> > 
> > Thanks, but those new changes will only make sense after merging the Xen tree
> > with the PM tree.  Why don't we queue them up for merging later after both
> > the Xen and PM trees have been pulled from?
> 
> OK, I've created a branch (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
> that has your branch and my branch - along with the fix from Stephan and then
> the three updates from Jinsong. Jinsong, please check that I've got all the
> right patches. I will rebase it once Linus has merged both of the Xen and PM trees.

Thanks, this looks good.

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

RE: linux-next: build failure after merge of the xen-two tree

[Liu, Jinsong]

Konrad Rzeszutek Wilk wrote:
>>>> commit 3757b94802fb65d8f696597a74053cf21738da0b
>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>> Date:   Wed Feb 13 14:36:47 2013 +0100
>>>> 
>>>>     ACPI / hotplug: Fix concurrency issues and memory leaks
>>>> 
>>>> after which acpi_bus_scan() and acpi_bus_trim() have to be run
>>>> under acpi_scan_lock (new in my tree as well).
>>> 
>>> Yes, we noticed that and only need minor updates at xen side, will
>>> send out 2 xen patches later accordingly, for cleanup and adding
>>> lock. 
>> 
>> Thanks, but those new changes will only make sense after merging the
>> Xen tree with the PM tree.  Why don't we queue them up for merging
>> later after both the Xen and PM trees have been pulled from?
> 
> OK, I've created a branch
> (http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next-resolved)
> that has your branch and my branch - along with the fix from Stephan
> and then  
> the three updates from Jinsong. Jinsong, please check that I've got
> all the 
> right patches. I will rebase it once Linus has merged both of the Xen
> and PM trees. 

Check done, it's OK.

Thanks,
Jinsong

RE: linux-next: build failure after merge of the xen-two tree

[Liu, Jinsong]

Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 15, 2013 at 03:45:51PM +1100, Stephen Rothwell wrote:
>> Hi Konrad,
>> 
>> After merging the xen-two tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
> 
> Good morning!
>> 
>> drivers/xen/xen-acpi-memhotplug.c: In function
>> 'acpi_memory_get_device': 
>> drivers/xen/xen-acpi-memhotplug.c:191:2: error: implicit declaration
>> of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
>> drivers/xen/xen-acpi-memhotplug.c: At top level: 
>> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: initialization
>> from incompatible pointer type [enabled by default]
>> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: (near
>> initialization for 'xen_acpi_memory_device_driver.ops.remove')
>> [enabled by default]   
>> 
>> Caused by commit 259f201cb7ea ("xen/acpi: ACPI memory hotplug").
>> 
>> drivers/xen/xen-acpi-cpuhotplug.c: In function
>> 'acpi_processor_device_add': 
>> drivers/xen/xen-acpi-cpuhotplug.c:254:2: error: implicit declaration
>> of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
>> drivers/xen/xen-acpi-cpuhotplug.c: At top level: 
>> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: initialization
>> from incompatible pointer type [enabled by default]
>> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: (near
>> initialization for 'xen_acpi_processor_driver.ops.remove') [enabled
>> by default]   
>> 
>> Caused by commit 181232c249f0 ("xen/acpi: ACPI cpu hotplug").
> 
> Grrrreat! Jinsong, can you please fix that ? A patch on top of the
> #linux-next
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 

Done, warning fixed.

Thanks,
Jinsong

RE: linux-next: build failure after merge of the xen-two tree

[Liu, Jinsong]

Stephen Rothwell wrote:
> Hi Konrad,
> 
> After merging the xen-two tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/xen/xen-acpi-memhotplug.c: In function
> 'acpi_memory_get_device': 
> drivers/xen/xen-acpi-memhotplug.c:191:2: error: implicit declaration
> of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
> drivers/xen/xen-acpi-memhotplug.c: At top level: 
> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: initialization from
> incompatible pointer type [enabled by default]
> drivers/xen/xen-acpi-memhotplug.c:417:3: warning: (near
> initialization for 'xen_acpi_memory_device_driver.ops.remove')
> [enabled by default]   
> 
> Caused by commit 259f201cb7ea ("xen/acpi: ACPI memory hotplug").
> 
> drivers/xen/xen-acpi-cpuhotplug.c: In function
> 'acpi_processor_device_add': 
> drivers/xen/xen-acpi-cpuhotplug.c:254:2: error: implicit declaration
> of function 'acpi_bus_add' [-Werror=implicit-function-declaration]
> drivers/xen/xen-acpi-cpuhotplug.c: At top level: 
> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: initialization from
> incompatible pointer type [enabled by default]
> drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: (near
> initialization for 'xen_acpi_processor_driver.ops.remove') [enabled
> by default]   
> 
> Caused by commit 181232c249f0 ("xen/acpi: ACPI cpu hotplug").
> 
> These commits interacted with commits 636458de36f1 ("ACPI: Remove the
> arguments of acpi_bus_add() that are not used"), 0cd6ac52b333 ("ACPI:
> Make acpi_bus_scan() and acpi_bus_add() take only one argument") and
> b8bd759acd05 ("ACPI / scan: Drop acpi_bus_add() and use
> acpi_bus_scan() 
> instead") from the pm tree.
> 
> I have added this merge fix patch and can carry it as necessary (I did
> *not* fix the warnings above):

Thanks Stephen to fix the confliction between xen and pm tree!
As for the warnings above, I have just sent out a patch 1 minutes ago to fix it.

Regards,
Jinsong

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 15 Feb 2013 15:37:27 +1100
> Subject: [PATCH] xen/acpi: fix up for apci_bus_add api change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/xen/xen-acpi-cpuhotplug.c | 2 +-
>  drivers/xen/xen-acpi-memhotplug.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-acpi-cpuhotplug.c
> b/drivers/xen/xen-acpi-cpuhotplug.c 
> index 9eefbb0..0db4722 100644
> --- a/drivers/xen/xen-acpi-cpuhotplug.c
> +++ b/drivers/xen/xen-acpi-cpuhotplug.c
> @@ -251,7 +251,7 @@ int acpi_processor_device_add(acpi_handle handle,
>  	struct acpi_device **device) if (acpi_bus_get_device(phandle,
>  		&pdev)) return -ENODEV;
> 
> -	if (acpi_bus_add(device, pdev, handle, ACPI_BUS_TYPE_PROCESSOR))
> +	if (acpi_bus_scan(handle))
>  		return -ENODEV;
> 
>  	return 0;
> diff --git a/drivers/xen/xen-acpi-memhotplug.c
> b/drivers/xen/xen-acpi-memhotplug.c 
> index 678680c..164287b 100644
> --- a/drivers/xen/xen-acpi-memhotplug.c
> +++ b/drivers/xen/xen-acpi-memhotplug.c
> @@ -188,7 +188,7 @@ acpi_memory_get_device(acpi_handle handle,
>  	 * Now add the notified device.  This creates the acpi_device
>  	 * and invokes .add function
>  	 */
> -	result = acpi_bus_add(&device, pdevice, handle,
> ACPI_BUS_TYPE_DEVICE); +	result = acpi_bus_scan(handle);
>  	if (result) {
>  		pr_warn(PREFIX "Cannot add acpi bus\n");
>  		return -EINVAL;
> --
> 1.8.1

linux-next: build failure after merge of the xen-two tree

[Stephen Rothwell]

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

Hi Konrad,

After merging the xen-two tree, today's linux-next build (x86_64
allmodconfig) failed like this:

arch/x86/xen/mmu.c: In function 'xen_init_mmu_ops':
arch/x86/xen/mmu.c:2213:10: error: 'struct x86_init_ops' has no member named 'mapping'
arch/x86/xen/mmu.c:2213:39: error: 'xen_mapping_pagetable_reserve' undeclared (first use in this function)

Caused by commit 8154d7a6b9b9 ("xen/pvh: Implement MMU changes for PVH")
from the xen-two tree interacting with commit 6f80b68e9e51 ("x86, mm,
Xen: Remove mapping_pagetable_reserve()") from the tip tree.  The
automatic merge left the moved version of the above line intact while it
should have been removed (I assume).

I have added the following merge fix patch and can carry the fix as
necessary.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 4 Feb 2013 15:08:33 +1100
Subject: [PATCH] xen: fix bad merge of arch/x86/xen/mmu.c

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/xen/mmu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 824706a..3228600 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2210,7 +2210,6 @@ void __init xen_init_mmu_ops(void)
 		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
 		return;
 	}
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the xen-two tree

[Konrad Rzeszutek Wilk]

On Mon, Feb 04, 2013 at 03:14:56PM +1100, Stephen Rothwell wrote:
> Hi Konrad,
> 
> After merging the xen-two tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> arch/x86/xen/mmu.c: In function 'xen_init_mmu_ops':
> arch/x86/xen/mmu.c:2213:10: error: 'struct x86_init_ops' has no member named 'mapping'
> arch/x86/xen/mmu.c:2213:39: error: 'xen_mapping_pagetable_reserve' undeclared (first use in this function)
> 
> Caused by commit 8154d7a6b9b9 ("xen/pvh: Implement MMU changes for PVH")
> from the xen-two tree interacting with commit 6f80b68e9e51 ("x86, mm,
> Xen: Remove mapping_pagetable_reserve()") from the tip tree.  The
> automatic merge left the moved version of the above line intact while it
> should have been removed (I assume).
> 
> I have added the following merge fix patch and can carry the fix as
> necessary.

Ah yes. Please do. I will fix it up once I am back on the box that has
access to the kernel.org. Thanks again!

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 4 Feb 2013 15:08:33 +1100
> Subject: [PATCH] xen: fix bad merge of arch/x86/xen/mmu.c
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/xen/mmu.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 824706a..3228600 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -2210,7 +2210,6 @@ void __init xen_init_mmu_ops(void)
>  		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
>  		return;
>  	}
> -	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	pv_mmu_ops = xen_mmu_ops;
>  
>  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> -- 
> 1.8.1
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

Re: linux-next: build failure after merge of the xen-two tree

[Stephen Rothwell]

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

Hi Konrad,

On Tue, 5 Feb 2013 13:30:08 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
> On Mon, Feb 04, 2013 at 03:14:56PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the xen-two tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > arch/x86/xen/mmu.c: In function 'xen_init_mmu_ops':
> > arch/x86/xen/mmu.c:2213:10: error: 'struct x86_init_ops' has no member named 'mapping'
> > arch/x86/xen/mmu.c:2213:39: error: 'xen_mapping_pagetable_reserve' undeclared (first use in this function)
> > 
> > Caused by commit 8154d7a6b9b9 ("xen/pvh: Implement MMU changes for PVH")
> > from the xen-two tree interacting with commit 6f80b68e9e51 ("x86, mm,
> > Xen: Remove mapping_pagetable_reserve()") from the tip tree.  The
> > automatic merge left the moved version of the above line intact while it
> > should have been removed (I assume).
> > 
> > I have added the following merge fix patch and can carry the fix as
> > necessary.
> 
> Ah yes. Please do. I will fix it up once I am back on the box that has
> access to the kernel.org. Thanks again!
> 
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 4 Feb 2013 15:08:33 +1100
> > Subject: [PATCH] xen: fix bad merge of arch/x86/xen/mmu.c
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  arch/x86/xen/mmu.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index 824706a..3228600 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -2210,7 +2210,6 @@ void __init xen_init_mmu_ops(void)
> >  		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> >  		return;
> >  	}
> > -	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
> >  	pv_mmu_ops = xen_mmu_ops;
> >  
> >  	memset(dummy_mapping, 0xff, PAGE_SIZE);

I am still carrying this merge fix patch and from a quick look, your tree
should need it now to even build ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: build failure after merge of the xen-two tree

[Stephen Rothwell]

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

Hi Konrad,

After merging the xen-two tree, today's linux-next build (x86_64
allmodconfig) failed like this:

arch/x86/built-in.o: In function `xen_start_kernel':
(.init.text+0xa88): undefined reference to `xen_acpi_notify_hypervisor_state'
drivers/built-in.o: In function `dbgp_reset_prep':
(.text+0x12ddeb): undefined reference to `xen_dbgp_reset_prep'
drivers/built-in.o: In function `dbgp_external_startup':
(.text+0x12e6a9): undefined reference to `xen_dbgp_external_startup'

I have used the xen-two tree from next-20121001 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: build failure after merge of the xen-two tree

[Stephen Rothwell]

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

Hi Konrad,

After merging the xen-two tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler':
drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip'
drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip'

Caused by commit e22ff7614860bc282ba1eb25440d8fc56975e357 ("xen:
Interrupt cleanups").

I have used the version of the xen-two tree from next-20110209 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: build failure after merge of the xen-two tree

[Thomas Gleixner]

On Thu, 10 Feb 2011, Stephen Rothwell wrote:

> Hi Konrad,
> 
> After merging the xen-two tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler':
> drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip'
> drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip'
> 
> Caused by commit e22ff7614860bc282ba1eb25440d8fc56975e357 ("xen:
> Interrupt cleanups").

Argh, it selects:

+       select GENERIC_HARDIRQS_NO_DEPRECATED

Konrad, I merily asked you to test XEN with that flag set, not to
apply the change.

Thanks,

	tglx

Re: linux-next: build failure after merge of the xen-two tree

[Konrad Rzeszutek Wilk]

On Thu, Feb 10, 2011 at 01:24:58PM +0100, Thomas Gleixner wrote:
> On Thu, 10 Feb 2011, Stephen Rothwell wrote:
> 
> > Hi Konrad,
> > 
> > After merging the xen-two tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler':
> > drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip'
> > drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip'
> > 
> > Caused by commit e22ff7614860bc282ba1eb25440d8fc56975e357 ("xen:
> > Interrupt cleanups").
> 
> Argh, it selects:
> 
> +       select GENERIC_HARDIRQS_NO_DEPRECATED
> 
> Konrad, I merily asked you to test XEN with that flag set, not to
> apply the change.

Whoops. Looks that I forgot to back out the change after I tested it. It is gone now.