Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

Hi Ard,

I have observe what appears to be a build regression in next-20150323
caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").

# make
...
arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error

I have observed this using the cross-compiler that is available on kernel.org:

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/

# arm-unknown-linux-gnueabi-gcc --version
arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# arm-unknown-linux-gnueabi-ld --version
GNU ld (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

Hi Ard,

I have observe what appears to be a build regression in next-20150323
caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").

# make
...
arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error

I have observed this using the cross-compiler that is available on kernel.org:

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/

# arm-unknown-linux-gnueabi-gcc --version
arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# arm-unknown-linux-gnueabi-ld --version
GNU ld (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

Hi Simon,

On 23 March 2015 at 17:45, Simon Horman <horms@verge.net.au> wrote:
> Hi Ard,
>
> I have observe what appears to be a build regression in next-20150323
> caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
>
> # make
> ...
> arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
>
> I have observed this using the cross-compiler that is available on kernel.org:
>
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
>
> # arm-unknown-linux-gnueabi-gcc --version
> arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # arm-unknown-linux-gnueabi-ld --version
> GNU ld (GNU Binutils) 2.22
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.

I've also ran into this issue here[1], and can confirm that patch
causes problems with gcc 4.6 and gcc 4.7.

>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


[1] http://lists.linaro.org/pipermail/kernel-build-reports/2015-March/007884.html

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

Hi Simon,

On 23 March 2015 at 17:45, Simon Horman <horms@verge.net.au> wrote:
> Hi Ard,
>
> I have observe what appears to be a build regression in next-20150323
> caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
>
> # make
> ...
> arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
>
> I have observed this using the cross-compiler that is available on kernel.org:
>
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
>
> # arm-unknown-linux-gnueabi-gcc --version
> arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # arm-unknown-linux-gnueabi-ld --version
> GNU ld (GNU Binutils) 2.22
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.

I've also ran into this issue here[1], and can confirm that patch
causes problems with gcc 4.6 and gcc 4.7.

>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


[1] http://lists.linaro.org/pipermail/kernel-build-reports/2015-March/007884.html

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

On 23 March 2015 at 17:52, Tyler Baker <tyler.baker@linaro.org> wrote:
> Hi Simon,
>
> On 23 March 2015 at 17:45, Simon Horman <horms@verge.net.au> wrote:
>> Hi Ard,
>>
>> I have observe what appears to be a build regression in next-20150323
>> caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
>>
>> # make
>> ...
>> arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
>>
>> I have observed this using the cross-compiler that is available on kernel.org:
>>
>> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
>>
>> # arm-unknown-linux-gnueabi-gcc --version
>> arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
>> Copyright (C) 2011 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> # arm-unknown-linux-gnueabi-ld --version
>> GNU ld (GNU Binutils) 2.22
>> Copyright 2011 Free Software Foundation, Inc.
>> This program is free software; you may redistribute it under the terms of
>> the GNU General Public License version 3 or (at your option) a later version.
>> This program has absolutely no warranty.
>
> I've also ran into this issue here[1], and can confirm that patch
> causes problems with gcc 4.6 and gcc 4.7.
>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> [1] http://lists.linaro.org/pipermail/kernel-build-reports/2015-March/007884.html

Copy and paste error. Here is the correct link[1]


[1] http://lists.linaro.org/pipermail/kernel-build-reports/2015-March/008183.html

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

On 23 March 2015 at 17:52, Tyler Baker <tyler.baker@linaro.org> wrote:
> Hi Simon,
>
> On 23 March 2015 at 17:45, Simon Horman <horms@verge.net.au> wrote:
>> Hi Ard,
>>
>> I have observe what appears to be a build regression in next-20150323
>> caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
>>
>> # make
>> ...
>> arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
>>
>> I have observed this using the cross-compiler that is available on kernel.org:
>>
>> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
>>
>> # arm-unknown-linux-gnueabi-gcc --version
>> arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
>> Copyright (C) 2011 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> # arm-unknown-linux-gnueabi-ld --version
>> GNU ld (GNU Binutils) 2.22
>> Copyright 2011 Free Software Foundation, Inc.
>> This program is free software; you may redistribute it under the terms of
>> the GNU General Public License version 3 or (at your option) a later version.
>> This program has absolutely no warranty.
>
> I've also ran into this issue here[1], and can confirm that patch
> causes problems with gcc 4.6 and gcc 4.7.
>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> [1] http://lists.linaro.org/pipermail/kernel-build-reports/2015-March/007884.html

Copy and paste error. Here is the correct link[1]


[1] http://lists.linaro.org/pipermail/kernel-build-reports/2015-March/008183.html

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Ard Biesheuvel]

On 24 March 2015 at 01:45, Simon Horman <horms@verge.net.au> wrote:
> Hi Ard,
>
> I have observe what appears to be a build regression in next-20150323
> caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
>
> # make
> ...
> arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
>
> I have observed this using the cross-compiler that is available on kernel.org:
>
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
>
> # arm-unknown-linux-gnueabi-gcc --version
> arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # arm-unknown-linux-gnueabi-ld --version
> GNU ld (GNU Binutils) 2.22
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
>

Hi all,

This is fixed now in next-20150324.
Sorry for the trouble

-- 
Ard.

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Ard Biesheuvel]

On 24 March 2015 at 01:45, Simon Horman <horms@verge.net.au> wrote:
> Hi Ard,
>
> I have observe what appears to be a build regression in next-20150323
> caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
>
> # make
> ...
> arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
>
> I have observed this using the cross-compiler that is available on kernel.org:
>
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
>
> # arm-unknown-linux-gnueabi-gcc --version
> arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # arm-unknown-linux-gnueabi-ld --version
> GNU ld (GNU Binutils) 2.22
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
>

Hi all,

This is fixed now in next-20150324.
Sorry for the trouble

-- 
Ard.

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Nishanth Menon]

On 09:31-20150324, Ard Biesheuvel wrote:
> On 24 March 2015 at 01:45, Simon Horman <horms@verge.net.au> wrote:
> > Hi Ard,
> >
> > I have observe what appears to be a build regression in next-20150323
> > caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
> >
> > # make
> > ...
> > arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
> >
> > I have observed this using the cross-compiler that is available on kernel.org:
> >
> > https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
> >
> > # arm-unknown-linux-gnueabi-gcc --version
> > arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> > Copyright (C) 2011 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > # arm-unknown-linux-gnueabi-ld --version
> > GNU ld (GNU Binutils) 2.22
> > Copyright 2011 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms of
> > the GNU General Public License version 3 or (at your option) a later version.
> > This program has absolutely no warranty.
> >
> 
> Hi all,
> 
> This is fixed now in next-20150324.
> Sorry for the trouble

I think we now have a new error: (seen with omap2plus_defconfig)
on next-20150324 :
./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
referenced in expression
make: *** [vmlinux] Error 1

cross compiler (from ubuntu 12.04):
$ arm-linux-gnueabi-ld --version
GNU ld (GNU Binutils for Ubuntu) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

next-20150320 was the last kernel which was successfully built
-- 
Regards,
Nishanth Menon

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Nishanth Menon]

On 09:31-20150324, Ard Biesheuvel wrote:
> On 24 March 2015 at 01:45, Simon Horman <horms@verge.net.au> wrote:
> > Hi Ard,
> >
> > I have observe what appears to be a build regression in next-20150323
> > caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
> >
> > # make
> > ...
> > arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
> >
> > I have observed this using the cross-compiler that is available on kernel.org:
> >
> > https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
> >
> > # arm-unknown-linux-gnueabi-gcc --version
> > arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> > Copyright (C) 2011 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > # arm-unknown-linux-gnueabi-ld --version
> > GNU ld (GNU Binutils) 2.22
> > Copyright 2011 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms of
> > the GNU General Public License version 3 or (at your option) a later version.
> > This program has absolutely no warranty.
> >
> 
> Hi all,
> 
> This is fixed now in next-20150324.
> Sorry for the trouble

I think we now have a new error: (seen with omap2plus_defconfig)
on next-20150324 :
./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
referenced in expression
make: *** [vmlinux] Error 1

cross compiler (from ubuntu 12.04):
$ arm-linux-gnueabi-ld --version
GNU ld (GNU Binutils for Ubuntu) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

next-20150320 was the last kernel which was successfully built
-- 
Regards,
Nishanth Menon

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Nishanth Menon]

On 09:31-20150324, Ard Biesheuvel wrote:
> On 24 March 2015 at 01:45, Simon Horman <horms@verge.net.au> wrote:
> > Hi Ard,
> >
> > I have observe what appears to be a build regression in next-20150323
> > caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
> >
> > # make
> > ...
> > arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
> >
> > I have observed this using the cross-compiler that is available on kernel.org:
> >
> > https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
> >
> > # arm-unknown-linux-gnueabi-gcc --version
> > arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> > Copyright (C) 2011 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > # arm-unknown-linux-gnueabi-ld --version
> > GNU ld (GNU Binutils) 2.22
> > Copyright 2011 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms of
> > the GNU General Public License version 3 or (at your option) a later version.
> > This program has absolutely no warranty.
> >
> 
> Hi all,
> 
> This is fixed now in next-20150324.
> Sorry for the trouble

I think we now have a new error: (seen with omap2plus_defconfig)
on next-20150324 :
./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
referenced in expression
make: *** [vmlinux] Error 1

cross compiler (from ubuntu 12.04):
$ arm-linux-gnueabi-ld --version
GNU ld (GNU Binutils for Ubuntu) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

next-20150320 was the last kernel which was successfully built
-- 
Regards,
Nishanth Menon

[PATCH] gpio: syscon: reduce message level when direction reg offset not in dt

[grygorii.strashko]

From: Grygorii Strashko <grygorii.strashko@linaro.org>

Now GPIO syscon driver produces bunch of warnings during the
boot of Kesytone 2 SoCs:
 gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset!
 gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset!

This message unintentionally was added using dev_err(), but its
actual log level is debug, because third cell of "ti,syscon-dev" is
optional.

Hence change it to dev_dbg() as it should be.

This patch fixes commit:
 5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt")

Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org>
---
 drivers/gpio/gpio-syscon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 257e298..045a952 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -219,7 +219,7 @@ static int syscon_gpio_probe(struct platform_device *pdev)
 		ret = of_property_read_u32_index(np, "gpio,syscon-dev", 2,
 						 &priv->dir_reg_offset);
 		if (ret)
-			dev_err(dev, "can't read the dir register offset!\n");
+			dev_dbg(dev, "can't read the dir register offset!\n");
 
 		priv->dir_reg_offset <<= 3;
 	}
-- 
1.9.1

Re: [PATCH] gpio: syscon: reduce message level when direction reg offset not in dt

[Murali Karicheri]

On 03/24/2015 02:42 PM, grygorii.strashko@linaro.org wrote:
> From: Grygorii Strashko<grygorii.strashko@linaro.org>
>
> Now GPIO syscon driver produces bunch of warnings during the
> boot of Kesytone 2 SoCs:
>   gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset!
>   gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset!
>
> This message unintentionally was added using dev_err(), but its
> actual log level is debug, because third cell of "ti,syscon-dev" is
> optional.
>
> Hence change it to dev_dbg() as it should be.
>
> This patch fixes commit:
>   5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt")
>
> Reported-by: Russell King<linux@arm.linux.org.uk>
> Signed-off-by: Grygorii Strashko<grygorii.strashko@linaro.org>
> ---
>   drivers/gpio/gpio-syscon.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
> index 257e298..045a952 100644
> --- a/drivers/gpio/gpio-syscon.c
> +++ b/drivers/gpio/gpio-syscon.c
> @@ -219,7 +219,7 @@ static int syscon_gpio_probe(struct platform_device *pdev)
>   		ret = of_property_read_u32_index(np, "gpio,syscon-dev", 2,
>   						&priv->dir_reg_offset);
>   		if (ret)
> -			dev_err(dev, "can't read the dir register offset!\n");
> +			dev_dbg(dev, "can't read the dir register offset!\n");
>
>   		priv->dir_reg_offset<<= 3;
>   	}

Tested this on K2HK EVM and found the error log is not appearing any more.

Tested-by: Murali Karicheri <m-karicheri2@ti.com>

-- 
Murali Karicheri
Linux Kernel, Texas Instruments

Re: [PATCH] gpio: syscon: reduce message level when direction reg offset not in dt

[Murali Karicheri]

On 03/24/2015 02:42 PM, grygorii.strashko@linaro.org wrote:
> From: Grygorii Strashko<grygorii.strashko@linaro.org>
>
> Now GPIO syscon driver produces bunch of warnings during the
> boot of Kesytone 2 SoCs:
>   gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset!
>   gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset!
>
> This message unintentionally was added using dev_err(), but its
> actual log level is debug, because third cell of "ti,syscon-dev" is
> optional.
>
> Hence change it to dev_dbg() as it should be.
>
> This patch fixes commit:
>   5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt")
>
> Reported-by: Russell King<linux@arm.linux.org.uk>
> Signed-off-by: Grygorii Strashko<grygorii.strashko@linaro.org>
> ---
>   drivers/gpio/gpio-syscon.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
> index 257e298..045a952 100644
> --- a/drivers/gpio/gpio-syscon.c
> +++ b/drivers/gpio/gpio-syscon.c
> @@ -219,7 +219,7 @@ static int syscon_gpio_probe(struct platform_device *pdev)
>   		ret = of_property_read_u32_index(np, "gpio,syscon-dev", 2,
>   						&priv->dir_reg_offset);
>   		if (ret)
> -			dev_err(dev, "can't read the dir register offset!\n");
> +			dev_dbg(dev, "can't read the dir register offset!\n");
>
>   		priv->dir_reg_offset<<= 3;
>   	}

Tested this on K2HK EVM and found the error log is not appearing any more.

Tested-by: Murali Karicheri <m-karicheri2@ti.com>

-- 
Murali Karicheri
Linux Kernel, Texas Instruments

Re: [PATCH] gpio: syscon: reduce message level when direction reg offset not in dt

[santosh shilimkar]

On 3/24/2015 11:42 AM, grygorii.strashko@linaro.org wrote:
> From: Grygorii Strashko <grygorii.strashko@linaro.org>
>
> Now GPIO syscon driver produces bunch of warnings during the
> boot of Kesytone 2 SoCs:
>   gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset!
>   gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset!
>
> This message unintentionally was added using dev_err(), but its
> actual log level is debug, because third cell of "ti,syscon-dev" is
> optional.
>
> Hence change it to dev_dbg() as it should be.
>
> This patch fixes commit:
>   5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt")
>
> Reported-by: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org>
> ---
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

Hi Nishanth,

On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> On 09:31-20150324, Ard Biesheuvel wrote:
> > On 24 March 2015 at 01:45, Simon Horman <horms@verge.net.au> wrote:
> > > Hi Ard,
> > >
> > > I have observe what appears to be a build regression in next-20150323
> > > caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
> > >
> > > # make
> > > ...
> > > arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
> > >
> > > I have observed this using the cross-compiler that is available on kernel.org:
> > >
> > > https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
> > >
> > > # arm-unknown-linux-gnueabi-gcc --version
> > > arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> > > Copyright (C) 2011 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions.  There is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > >
> > > # arm-unknown-linux-gnueabi-ld --version
> > > GNU ld (GNU Binutils) 2.22
> > > Copyright 2011 Free Software Foundation, Inc.
> > > This program is free software; you may redistribute it under the terms of
> > > the GNU General Public License version 3 or (at your option) a later version.
> > > This program has absolutely no warranty.
> > >
> > 
> > Hi all,
> > 
> > This is fixed now in next-20150324.
> > Sorry for the trouble
> 
> I think we now have a new error: (seen with omap2plus_defconfig)
> on next-20150324 :
> ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> referenced in expression
> make: *** [vmlinux] Error 1

Thanks, I am seeing that too.

My armchair suggestion is that the following should be reverted.

e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")

> cross compiler (from ubuntu 12.04):
> $ arm-linux-gnueabi-ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.22
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
> $ arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> next-20150320 was the last kernel which was successfully built

I have also confirmed that.

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

Hi Nishanth,

On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> On 09:31-20150324, Ard Biesheuvel wrote:
> > On 24 March 2015 at 01:45, Simon Horman <horms@verge.net.au> wrote:
> > > Hi Ard,
> > >
> > > I have observe what appears to be a build regression in next-20150323
> > > caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
> > >
> > > # make
> > > ...
> > > arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
> > >
> > > I have observed this using the cross-compiler that is available on kernel.org:
> > >
> > > https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
> > >
> > > # arm-unknown-linux-gnueabi-gcc --version
> > > arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> > > Copyright (C) 2011 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions.  There is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > >
> > > # arm-unknown-linux-gnueabi-ld --version
> > > GNU ld (GNU Binutils) 2.22
> > > Copyright 2011 Free Software Foundation, Inc.
> > > This program is free software; you may redistribute it under the terms of
> > > the GNU General Public License version 3 or (at your option) a later version.
> > > This program has absolutely no warranty.
> > >
> > 
> > Hi all,
> > 
> > This is fixed now in next-20150324.
> > Sorry for the trouble
> 
> I think we now have a new error: (seen with omap2plus_defconfig)
> on next-20150324 :
> ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> referenced in expression
> make: *** [vmlinux] Error 1

Thanks, I am seeing that too.

My armchair suggestion is that the following should be reverted.

e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")

> cross compiler (from ubuntu 12.04):
> $ arm-linux-gnueabi-ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.22
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
> $ arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> next-20150320 was the last kernel which was successfully built

I have also confirmed that.

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

Hi Nishanth,

On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> On 09:31-20150324, Ard Biesheuvel wrote:
> > On 24 March 2015 at 01:45, Simon Horman <horms@verge.net.au> wrote:
> > > Hi Ard,
> > >
> > > I have observe what appears to be a build regression in next-20150323
> > > caused by 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page").
> > >
> > > # make
> > > ...
> > > arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error
> > >
> > > I have observed this using the cross-compiler that is available on kernel.org:
> > >
> > > https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
> > >
> > > # arm-unknown-linux-gnueabi-gcc --version
> > > arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
> > > Copyright (C) 2011 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions.  There is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > >
> > > # arm-unknown-linux-gnueabi-ld --version
> > > GNU ld (GNU Binutils) 2.22
> > > Copyright 2011 Free Software Foundation, Inc.
> > > This program is free software; you may redistribute it under the terms of
> > > the GNU General Public License version 3 or (at your option) a later version.
> > > This program has absolutely no warranty.
> > >
> > 
> > Hi all,
> > 
> > This is fixed now in next-20150324.
> > Sorry for the trouble
> 
> I think we now have a new error: (seen with omap2plus_defconfig)
> on next-20150324 :
> ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> referenced in expression
> make: *** [vmlinux] Error 1

Thanks, I am seeing that too.

My armchair suggestion is that the following should be reverted.

e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")

> cross compiler (from ubuntu 12.04):
> $ arm-linux-gnueabi-ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.22
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
> $ arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> next-20150320 was the last kernel which was successfully built

I have also confirmed that.

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > I think we now have a new error: (seen with omap2plus_defconfig)
> > on next-20150324 :
> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > referenced in expression
> > make: *** [vmlinux] Error 1
> 
> Thanks, I am seeing that too.
> 
> My armchair suggestion is that the following should be reverted.
> 
> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")

Can you try again with the latest -next please? We've merged an additional
patch aimed at sorting this out. Reverting isn't really an option, as
there's an awful lot of code that depends on the bounce page removal.

Will

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > I think we now have a new error: (seen with omap2plus_defconfig)
> > on next-20150324 :
> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > referenced in expression
> > make: *** [vmlinux] Error 1
> 
> Thanks, I am seeing that too.
> 
> My armchair suggestion is that the following should be reverted.
> 
> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")

Can you try again with the latest -next please? We've merged an additional
patch aimed at sorting this out. Reverting isn't really an option, as
there's an awful lot of code that depends on the bounce page removal.

Will

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > I think we now have a new error: (seen with omap2plus_defconfig)
> > on next-20150324 :
> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > referenced in expression
> > make: *** [vmlinux] Error 1
> 
> Thanks, I am seeing that too.
> 
> My armchair suggestion is that the following should be reverted.
> 
> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")

Can you try again with the latest -next please? We've merged an additional
patch aimed at sorting this out. Reverting isn't really an option, as
there's an awful lot of code that depends on the bounce page removal.

Will

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>> > I think we now have a new error: (seen with omap2plus_defconfig)
>> > on next-20150324 :
>> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>> > referenced in expression
>> > make: *** [vmlinux] Error 1
>>
>> Thanks, I am seeing that too.
>>
>> My armchair suggestion is that the following should be reverted.
>>
>> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>
> Can you try again with the latest -next please? We've merged an additional
> patch aimed at sorting this out. Reverting isn't really an option, as
> there's an awful lot of code that depends on the bounce page removal.

Here are the kernelci.org -next results[1], if you click the build
status you can dig down into the build failures. next-20150326 has now
hit a compiler bug, Arnd mentioned he was looking into this issue.

>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



[1] http://kernelci.org/job/next/

Tyler

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>> > I think we now have a new error: (seen with omap2plus_defconfig)
>> > on next-20150324 :
>> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>> > referenced in expression
>> > make: *** [vmlinux] Error 1
>>
>> Thanks, I am seeing that too.
>>
>> My armchair suggestion is that the following should be reverted.
>>
>> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>
> Can you try again with the latest -next please? We've merged an additional
> patch aimed at sorting this out. Reverting isn't really an option, as
> there's an awful lot of code that depends on the bounce page removal.

Here are the kernelci.org -next results[1], if you click the build
status you can dig down into the build failures. next-20150326 has now
hit a compiler bug, Arnd mentioned he was looking into this issue.

>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



[1] http://kernelci.org/job/next/

Tyler

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>> > I think we now have a new error: (seen with omap2plus_defconfig)
>> > on next-20150324 :
>> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>> > referenced in expression
>> > make: *** [vmlinux] Error 1
>>
>> Thanks, I am seeing that too.
>>
>> My armchair suggestion is that the following should be reverted.
>>
>> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>
> Can you try again with the latest -next please? We've merged an additional
> patch aimed at sorting this out. Reverting isn't really an option, as
> there's an awful lot of code that depends on the bounce page removal.

Here are the kernelci.org -next results[1], if you click the build
status you can dig down into the build failures. next-20150326 has now
hit a compiler bug, Arnd mentioned he was looking into this issue.

>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



[1] http://kernelci.org/job/next/

Tyler

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> >> > I think we now have a new error: (seen with omap2plus_defconfig)
> >> > on next-20150324 :
> >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> >> > referenced in expression
> >> > make: *** [vmlinux] Error 1
> >>
> >> Thanks, I am seeing that too.
> >>
> >> My armchair suggestion is that the following should be reverted.
> >>
> >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> >
> > Can you try again with the latest -next please? We've merged an additional
> > patch aimed at sorting this out. Reverting isn't really an option, as
> > there's an awful lot of code that depends on the bounce page removal.
> 
> Here are the kernelci.org -next results[1], if you click the build
> status you can dig down into the build failures. next-20150326 has now
> hit a compiler bug, Arnd mentioned he was looking into this issue.

I have confirmed that next-20150326 does not compile without
the following reverted:

12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> >> > I think we now have a new error: (seen with omap2plus_defconfig)
> >> > on next-20150324 :
> >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> >> > referenced in expression
> >> > make: *** [vmlinux] Error 1
> >>
> >> Thanks, I am seeing that too.
> >>
> >> My armchair suggestion is that the following should be reverted.
> >>
> >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> >
> > Can you try again with the latest -next please? We've merged an additional
> > patch aimed at sorting this out. Reverting isn't really an option, as
> > there's an awful lot of code that depends on the bounce page removal.
> 
> Here are the kernelci.org -next results[1], if you click the build
> status you can dig down into the build failures. next-20150326 has now
> hit a compiler bug, Arnd mentioned he was looking into this issue.

I have confirmed that next-20150326 does not compile without
the following reverted:

12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> >> > I think we now have a new error: (seen with omap2plus_defconfig)
> >> > on next-20150324 :
> >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> >> > referenced in expression
> >> > make: *** [vmlinux] Error 1
> >>
> >> Thanks, I am seeing that too.
> >>
> >> My armchair suggestion is that the following should be reverted.
> >>
> >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> >
> > Can you try again with the latest -next please? We've merged an additional
> > patch aimed at sorting this out. Reverting isn't really an option, as
> > there's an awful lot of code that depends on the bounce page removal.
> 
> Here are the kernelci.org -next results[1], if you click the build
> status you can dig down into the build failures. next-20150326 has now
> hit a compiler bug, Arnd mentioned he was looking into this issue.

I have confirmed that next-20150326 does not compile without
the following reverted:

12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> > >> > on next-20150324 :
> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > >> > referenced in expression
> > >> > make: *** [vmlinux] Error 1
> > >>
> > >> Thanks, I am seeing that too.
> > >>
> > >> My armchair suggestion is that the following should be reverted.
> > >>
> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> > >
> > > Can you try again with the latest -next please? We've merged an additional
> > > patch aimed at sorting this out. Reverting isn't really an option, as
> > > there's an awful lot of code that depends on the bounce page removal.
> > 
> > Here are the kernelci.org -next results[1], if you click the build
> > status you can dig down into the build failures. next-20150326 has now
> > hit a compiler bug, Arnd mentioned he was looking into this issue.
> 
> I have confirmed that next-20150326 does not compile without
> the following reverted:
> 
> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")

Thanks for testing this and sorry for the continued breakage. Which
toolchain did you say you were using? Ard has some more patches trying to
fix this, but none of our toolchains seem to tickle the issue.

Will

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> > >> > on next-20150324 :
> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > >> > referenced in expression
> > >> > make: *** [vmlinux] Error 1
> > >>
> > >> Thanks, I am seeing that too.
> > >>
> > >> My armchair suggestion is that the following should be reverted.
> > >>
> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> > >
> > > Can you try again with the latest -next please? We've merged an additional
> > > patch aimed at sorting this out. Reverting isn't really an option, as
> > > there's an awful lot of code that depends on the bounce page removal.
> > 
> > Here are the kernelci.org -next results[1], if you click the build
> > status you can dig down into the build failures. next-20150326 has now
> > hit a compiler bug, Arnd mentioned he was looking into this issue.
> 
> I have confirmed that next-20150326 does not compile without
> the following reverted:
> 
> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")

Thanks for testing this and sorry for the continued breakage. Which
toolchain did you say you were using? Ard has some more patches trying to
fix this, but none of our toolchains seem to tickle the issue.

Will

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> > >> > on next-20150324 :
> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > >> > referenced in expression
> > >> > make: *** [vmlinux] Error 1
> > >>
> > >> Thanks, I am seeing that too.
> > >>
> > >> My armchair suggestion is that the following should be reverted.
> > >>
> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> > >
> > > Can you try again with the latest -next please? We've merged an additional
> > > patch aimed at sorting this out. Reverting isn't really an option, as
> > > there's an awful lot of code that depends on the bounce page removal.
> > 
> > Here are the kernelci.org -next results[1], if you click the build
> > status you can dig down into the build failures. next-20150326 has now
> > hit a compiler bug, Arnd mentioned he was looking into this issue.
> 
> I have confirmed that next-20150326 does not compile without
> the following reverted:
> 
> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")

Thanks for testing this and sorry for the continued breakage. Which
toolchain did you say you were using? Ard has some more patches trying to
fix this, but none of our toolchains seem to tickle the issue.

Will

Re: [PATCH] gpio: syscon: reduce message level when direction reg offset not in dt

[Linus Walleij]

On Tue, Mar 24, 2015 at 7:42 PM,  <grygorii.strashko@linaro.org> wrote:

> From: Grygorii Strashko <grygorii.strashko@linaro.org>
>
> Now GPIO syscon driver produces bunch of warnings during the
> boot of Kesytone 2 SoCs:
>  gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset!
>  gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset!
>
> This message unintentionally was added using dev_err(), but its
> actual log level is debug, because third cell of "ti,syscon-dev" is
> optional.
>
> Hence change it to dev_dbg() as it should be.
>
> This patch fixes commit:
>  5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt")
>
> Reported-by: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org>

OK sorry for missing this when asking about the strange messages.
Patch applied for fixes with these test tags and ack.

Yours,
Linus Walleij

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

On Fri, Mar 27, 2015 at 10:06:12AM +0000, Will Deacon wrote:
> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> > On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> > > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> > > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> > > >> > on next-20150324 :
> > > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > > >> > referenced in expression
> > > >> > make: *** [vmlinux] Error 1
> > > >>
> > > >> Thanks, I am seeing that too.
> > > >>
> > > >> My armchair suggestion is that the following should be reverted.
> > > >>
> > > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> > > >
> > > > Can you try again with the latest -next please? We've merged an additional
> > > > patch aimed at sorting this out. Reverting isn't really an option, as
> > > > there's an awful lot of code that depends on the bounce page removal.
> > > 
> > > Here are the kernelci.org -next results[1], if you click the build
> > > status you can dig down into the build failures. next-20150326 has now
> > > hit a compiler bug, Arnd mentioned he was looking into this issue.
> > 
> > I have confirmed that next-20150326 does not compile without
> > the following reverted:
> > 
> > 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> > e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
> 
> Thanks for testing this and sorry for the continued breakage. Which
> toolchain did you say you were using? Ard has some more patches trying to
> fix this, but none of our toolchains seem to tickle the issue.

It seems that a fix has emerged (thanks! local testing looks good so far)
but for the record I am using the arm (32) tool chain for x86_84
on kernel.org.

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/

# arm-unknown-linux-gnueabi-gcc --version
arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# arm-unknown-linux-gnueabi-ld --version
GNU ld (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

On Fri, Mar 27, 2015 at 10:06:12AM +0000, Will Deacon wrote:
> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> > On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> > > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> > > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> > > >> > on next-20150324 :
> > > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > > >> > referenced in expression
> > > >> > make: *** [vmlinux] Error 1
> > > >>
> > > >> Thanks, I am seeing that too.
> > > >>
> > > >> My armchair suggestion is that the following should be reverted.
> > > >>
> > > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> > > >
> > > > Can you try again with the latest -next please? We've merged an additional
> > > > patch aimed at sorting this out. Reverting isn't really an option, as
> > > > there's an awful lot of code that depends on the bounce page removal.
> > > 
> > > Here are the kernelci.org -next results[1], if you click the build
> > > status you can dig down into the build failures. next-20150326 has now
> > > hit a compiler bug, Arnd mentioned he was looking into this issue.
> > 
> > I have confirmed that next-20150326 does not compile without
> > the following reverted:
> > 
> > 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> > e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
> 
> Thanks for testing this and sorry for the continued breakage. Which
> toolchain did you say you were using? Ard has some more patches trying to
> fix this, but none of our toolchains seem to tickle the issue.

It seems that a fix has emerged (thanks! local testing looks good so far)
but for the record I am using the arm (32) tool chain for x86_84
on kernel.org.

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/

# arm-unknown-linux-gnueabi-gcc --version
arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# arm-unknown-linux-gnueabi-ld --version
GNU ld (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Simon Horman]

On Fri, Mar 27, 2015 at 10:06:12AM +0000, Will Deacon wrote:
> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> > On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> > > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> > > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> > > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> > > >> > on next-20150324 :
> > > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> > > >> > referenced in expression
> > > >> > make: *** [vmlinux] Error 1
> > > >>
> > > >> Thanks, I am seeing that too.
> > > >>
> > > >> My armchair suggestion is that the following should be reverted.
> > > >>
> > > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> > > >
> > > > Can you try again with the latest -next please? We've merged an additional
> > > > patch aimed at sorting this out. Reverting isn't really an option, as
> > > > there's an awful lot of code that depends on the bounce page removal.
> > > 
> > > Here are the kernelci.org -next results[1], if you click the build
> > > status you can dig down into the build failures. next-20150326 has now
> > > hit a compiler bug, Arnd mentioned he was looking into this issue.
> > 
> > I have confirmed that next-20150326 does not compile without
> > the following reverted:
> > 
> > 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> > e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> > 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
> 
> Thanks for testing this and sorry for the continued breakage. Which
> toolchain did you say you were using? Ard has some more patches trying to
> fix this, but none of our toolchains seem to tickle the issue.

It seems that a fix has emerged (thanks! local testing looks good so far)
but for the record I am using the arm (32) tool chain for x86_84
on kernel.org.

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/

# arm-unknown-linux-gnueabi-gcc --version
arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# arm-unknown-linux-gnueabi-ld --version
GNU ld (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

On 27 March 2015 at 03:06, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
>> > >> > on next-20150324 :
>> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>> > >> > referenced in expression
>> > >> > make: *** [vmlinux] Error 1
>> > >>
>> > >> Thanks, I am seeing that too.
>> > >>
>> > >> My armchair suggestion is that the following should be reverted.
>> > >>
>> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>> > >
>> > > Can you try again with the latest -next please? We've merged an additional
>> > > patch aimed at sorting this out. Reverting isn't really an option, as
>> > > there's an awful lot of code that depends on the bounce page removal.
>> >
>> > Here are the kernelci.org -next results[1], if you click the build
>> > status you can dig down into the build failures. next-20150326 has now
>> > hit a compiler bug, Arnd mentioned he was looking into this issue.
>>
>> I have confirmed that next-20150326 does not compile without
>> the following reverted:
>>
>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>
> Thanks for testing this and sorry for the continued breakage. Which
> toolchain did you say you were using? Ard has some more patches trying to
> fix this, but none of our toolchains seem to tickle the issue.

I am able to reproduce with this toolchain[1].

>
> Will



[1] http://releases.linaro.org/12.10/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2

Tyler

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

On 27 March 2015 at 03:06, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
>> > >> > on next-20150324 :
>> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>> > >> > referenced in expression
>> > >> > make: *** [vmlinux] Error 1
>> > >>
>> > >> Thanks, I am seeing that too.
>> > >>
>> > >> My armchair suggestion is that the following should be reverted.
>> > >>
>> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>> > >
>> > > Can you try again with the latest -next please? We've merged an additional
>> > > patch aimed at sorting this out. Reverting isn't really an option, as
>> > > there's an awful lot of code that depends on the bounce page removal.
>> >
>> > Here are the kernelci.org -next results[1], if you click the build
>> > status you can dig down into the build failures. next-20150326 has now
>> > hit a compiler bug, Arnd mentioned he was looking into this issue.
>>
>> I have confirmed that next-20150326 does not compile without
>> the following reverted:
>>
>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>
> Thanks for testing this and sorry for the continued breakage. Which
> toolchain did you say you were using? Ard has some more patches trying to
> fix this, but none of our toolchains seem to tickle the issue.

I am able to reproduce with this toolchain[1].

>
> Will



[1] http://releases.linaro.org/12.10/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2

Tyler

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Tyler Baker]

On 27 March 2015 at 03:06, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
>> > >> > on next-20150324 :
>> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>> > >> > referenced in expression
>> > >> > make: *** [vmlinux] Error 1
>> > >>
>> > >> Thanks, I am seeing that too.
>> > >>
>> > >> My armchair suggestion is that the following should be reverted.
>> > >>
>> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>> > >
>> > > Can you try again with the latest -next please? We've merged an additional
>> > > patch aimed at sorting this out. Reverting isn't really an option, as
>> > > there's an awful lot of code that depends on the bounce page removal.
>> >
>> > Here are the kernelci.org -next results[1], if you click the build
>> > status you can dig down into the build failures. next-20150326 has now
>> > hit a compiler bug, Arnd mentioned he was looking into this issue.
>>
>> I have confirmed that next-20150326 does not compile without
>> the following reverted:
>>
>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>
> Thanks for testing this and sorry for the continued breakage. Which
> toolchain did you say you were using? Ard has some more patches trying to
> fix this, but none of our toolchains seem to tickle the issue.

I am able to reproduce with this toolchain[1].

>
> Will



[1] http://releases.linaro.org/12.10/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2

Tyler

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Kevin Hilman]

Will, Ard,

Will Deacon <will.deacon@arm.com> writes:

> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
>> > >> > on next-20150324 :
>> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>> > >> > referenced in expression
>> > >> > make: *** [vmlinux] Error 1
>> > >>
>> > >> Thanks, I am seeing that too.
>> > >>
>> > >> My armchair suggestion is that the following should be reverted.
>> > >>
>> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>> > >
>> > > Can you try again with the latest -next please? We've merged an additional
>> > > patch aimed at sorting this out. Reverting isn't really an option, as
>> > > there's an awful lot of code that depends on the bounce page removal.
>> > 
>> > Here are the kernelci.org -next results[1], if you click the build
>> > status you can dig down into the build failures. next-20150326 has now
>> > hit a compiler bug, Arnd mentioned he was looking into this issue.
>> 
>> I have confirmed that next-20150326 does not compile without
>> the following reverted:
>> 
>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>
> Thanks for testing this and sorry for the continued breakage. Which
> toolchain did you say you were using? Ard has some more patches trying to
> fix this, but none of our toolchains seem to tickle the issue.

I've also tested on the default ARM toolchains available with ubuntu[1]

Are there any updates on this issue?

It ha broken most of the ARM defconfigs in linux-next[2], and since it's
been broken for a week now, it is masking other types of issues that we
can normally find via automated boot testing.

Kevin


[1]
arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.2-16ubuntu4) 4.8.2
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3

[2] http://kernelci.org/job/next/

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Kevin Hilman]

Will, Ard,

Will Deacon <will.deacon@arm.com> writes:

> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
>> > >> > on next-20150324 :
>> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>> > >> > referenced in expression
>> > >> > make: *** [vmlinux] Error 1
>> > >>
>> > >> Thanks, I am seeing that too.
>> > >>
>> > >> My armchair suggestion is that the following should be reverted.
>> > >>
>> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>> > >
>> > > Can you try again with the latest -next please? We've merged an additional
>> > > patch aimed at sorting this out. Reverting isn't really an option, as
>> > > there's an awful lot of code that depends on the bounce page removal.
>> > 
>> > Here are the kernelci.org -next results[1], if you click the build
>> > status you can dig down into the build failures. next-20150326 has now
>> > hit a compiler bug, Arnd mentioned he was looking into this issue.
>> 
>> I have confirmed that next-20150326 does not compile without
>> the following reverted:
>> 
>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>
> Thanks for testing this and sorry for the continued breakage. Which
> toolchain did you say you were using? Ard has some more patches trying to
> fix this, but none of our toolchains seem to tickle the issue.

I've also tested on the default ARM toolchains available with ubuntu[1]

Are there any updates on this issue?

It ha broken most of the ARM defconfigs in linux-next[2], and since it's
been broken for a week now, it is masking other types of issues that we
can normally find via automated boot testing.

Kevin


[1]
arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.2-16ubuntu4) 4.8.2
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3

[2] http://kernelci.org/job/next/

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Ard Biesheuvel]

On 31 March 2015 at 20:58, Kevin Hilman <khilman@kernel.org> wrote:
> Will, Ard,
>
> Will Deacon <will.deacon@arm.com> writes:
>
>> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>>> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>>> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>>> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>>> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
>>> > >> > on next-20150324 :
>>> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>>> > >> > referenced in expression
>>> > >> > make: *** [vmlinux] Error 1
>>> > >>
>>> > >> Thanks, I am seeing that too.
>>> > >>
>>> > >> My armchair suggestion is that the following should be reverted.
>>> > >>
>>> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>>> > >
>>> > > Can you try again with the latest -next please? We've merged an additional
>>> > > patch aimed at sorting this out. Reverting isn't really an option, as
>>> > > there's an awful lot of code that depends on the bounce page removal.
>>> >
>>> > Here are the kernelci.org -next results[1], if you click the build
>>> > status you can dig down into the build failures. next-20150326 has now
>>> > hit a compiler bug, Arnd mentioned he was looking into this issue.
>>>
>>> I have confirmed that next-20150326 does not compile without
>>> the following reverted:
>>>
>>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>>
>> Thanks for testing this and sorry for the continued breakage. Which
>> toolchain did you say you were using? Ard has some more patches trying to
>> fix this, but none of our toolchains seem to tickle the issue.
>
> I've also tested on the default ARM toolchains available with ubuntu[1]
>
> Are there any updates on this issue?
>

I think Will and I were both under the impression that this patch

https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=kvm-bounce-page

fixed the issue conclusively.

Could you elaborate on the issue please? What is the error you are
getting, and can you confirm that is is caused by ld choking on the
linker script? If not, this is another error than the one we have been
trying to fix

-- 
Ard.



> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
> been broken for a week now, it is masking other types of issues that we
> can normally find via automated boot testing.
>
> Kevin
>
>
> [1]
> arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.2-16ubuntu4) 4.8.2
> arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>
> [2] http://kernelci.org/job/next/

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Ard Biesheuvel]

On 31 March 2015 at 20:58, Kevin Hilman <khilman@kernel.org> wrote:
> Will, Ard,
>
> Will Deacon <will.deacon@arm.com> writes:
>
>> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>>> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>>> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>>> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>>> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
>>> > >> > on next-20150324 :
>>> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>>> > >> > referenced in expression
>>> > >> > make: *** [vmlinux] Error 1
>>> > >>
>>> > >> Thanks, I am seeing that too.
>>> > >>
>>> > >> My armchair suggestion is that the following should be reverted.
>>> > >>
>>> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>>> > >
>>> > > Can you try again with the latest -next please? We've merged an additional
>>> > > patch aimed at sorting this out. Reverting isn't really an option, as
>>> > > there's an awful lot of code that depends on the bounce page removal.
>>> >
>>> > Here are the kernelci.org -next results[1], if you click the build
>>> > status you can dig down into the build failures. next-20150326 has now
>>> > hit a compiler bug, Arnd mentioned he was looking into this issue.
>>>
>>> I have confirmed that next-20150326 does not compile without
>>> the following reverted:
>>>
>>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>>
>> Thanks for testing this and sorry for the continued breakage. Which
>> toolchain did you say you were using? Ard has some more patches trying to
>> fix this, but none of our toolchains seem to tickle the issue.
>
> I've also tested on the default ARM toolchains available with ubuntu[1]
>
> Are there any updates on this issue?
>

I think Will and I were both under the impression that this patch

https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=kvm-bounce-page

fixed the issue conclusively.

Could you elaborate on the issue please? What is the error you are
getting, and can you confirm that is is caused by ld choking on the
linker script? If not, this is another error than the one we have been
trying to fix

-- 
Ard.



> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
> been broken for a week now, it is masking other types of issues that we
> can normally find via automated boot testing.
>
> Kevin
>
>
> [1]
> arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.2-16ubuntu4) 4.8.2
> arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>
> [2] http://kernelci.org/job/next/

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Ard Biesheuvel]

On 31 March 2015 at 20:58, Kevin Hilman <khilman@kernel.org> wrote:
> Will, Ard,
>
> Will Deacon <will.deacon@arm.com> writes:
>
>> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>>> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>>> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>>> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>>> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
>>> > >> > on next-20150324 :
>>> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>>> > >> > referenced in expression
>>> > >> > make: *** [vmlinux] Error 1
>>> > >>
>>> > >> Thanks, I am seeing that too.
>>> > >>
>>> > >> My armchair suggestion is that the following should be reverted.
>>> > >>
>>> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>>> > >
>>> > > Can you try again with the latest -next please? We've merged an additional
>>> > > patch aimed at sorting this out. Reverting isn't really an option, as
>>> > > there's an awful lot of code that depends on the bounce page removal.
>>> >
>>> > Here are the kernelci.org -next results[1], if you click the build
>>> > status you can dig down into the build failures. next-20150326 has now
>>> > hit a compiler bug, Arnd mentioned he was looking into this issue.
>>>
>>> I have confirmed that next-20150326 does not compile without
>>> the following reverted:
>>>
>>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>>
>> Thanks for testing this and sorry for the continued breakage. Which
>> toolchain did you say you were using? Ard has some more patches trying to
>> fix this, but none of our toolchains seem to tickle the issue.
>
> I've also tested on the default ARM toolchains available with ubuntu[1]
>
> Are there any updates on this issue?
>

I think Will and I were both under the impression that this patch

https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=kvm-bounce-page

fixed the issue conclusively.

Could you elaborate on the issue please? What is the error you are
getting, and can you confirm that is is caused by ld choking on the
linker script? If not, this is another error than the one we have been
trying to fix

-- 
Ard.



> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
> been broken for a week now, it is masking other types of issues that we
> can normally find via automated boot testing.
>
> Kevin
>
>
> [1]
> arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.2-16ubuntu4) 4.8.2
> arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>
> [2] http://kernelci.org/job/next/

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Kevin Hilman]

Hi Ard,

Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:

[...]

> I think Will and I were both under the impression that this patch
>
> https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=kvm-bounce-page
>
> fixed the issue conclusively.

Nope, that branch is already part of linux-next, and linux-next still
fails to compile for 20+ defconfigs[1]

> Could you elaborate on the issue please? What is the error you are
> getting, and can you confirm that is is caused by ld choking on the
> linker script? If not, this is another error than the one we have been
> trying to fix

It's definitely not linker script related.

Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
here's the error when building for multi_v7_defconfig (full log
available[2]):

../mm/migrate.c: In function 'migrate_pages':
../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
this to your bugreport.
make[2]: *** [mm/migrate.o] Error 1
make[2]: Target `__build' not remade because of errors.
make[1]: *** [mm] Error 2

build bisect points to commit 21f992084aeb[3], but that doesn't revert
cleanly so I haven't got any further than that yet.

Kevin

[1] http://kernelci.org/build/next/kernel/next-20150331/
[2] http://storage.kernelci.org/next/next-20150331/arm-multi_v7_defconfig/build.log
[3] 21f992084aeb777675ba5f9c2dc6663e8a06e467 is the first bad commit

Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Wed Mar 25 13:02:28 2015 +1100

    page-flags: define behavior of FS/IO-related flags on compound pages

    It seems we don't have compound page on FS/IO path currently.  Use
    NO_COMPOUND to catch if we have.

    The odd exception is PG_dirty: sound uses compound pages and maps
    them
    with PTEs.  NO_COMPOUND triggers VM_BUG_ON() in set_page_dirty() on
    handling shared fault.  Let's use HEAD for PG_dirty.

    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Christoph Lameter <cl@linux.com> 
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Jerome Marchand <jmarchan@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

:040000 040000 0d621460af1123de8fc33c881ae314c914725afc
b843f45fb2a1c2537e8c17946d3f8af512cab84d M      include
bisect run success

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Kevin Hilman]

Hi Ard,

Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:

[...]

> I think Will and I were both under the impression that this patch
>
> https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=kvm-bounce-page
>
> fixed the issue conclusively.

Nope, that branch is already part of linux-next, and linux-next still
fails to compile for 20+ defconfigs[1]

> Could you elaborate on the issue please? What is the error you are
> getting, and can you confirm that is is caused by ld choking on the
> linker script? If not, this is another error than the one we have been
> trying to fix

It's definitely not linker script related.

Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
here's the error when building for multi_v7_defconfig (full log
available[2]):

../mm/migrate.c: In function 'migrate_pages':
../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
this to your bugreport.
make[2]: *** [mm/migrate.o] Error 1
make[2]: Target `__build' not remade because of errors.
make[1]: *** [mm] Error 2

build bisect points to commit 21f992084aeb[3], but that doesn't revert
cleanly so I haven't got any further than that yet.

Kevin

[1] http://kernelci.org/build/next/kernel/next-20150331/
[2] http://storage.kernelci.org/next/next-20150331/arm-multi_v7_defconfig/build.log
[3] 21f992084aeb777675ba5f9c2dc6663e8a06e467 is the first bad commit

Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Wed Mar 25 13:02:28 2015 +1100

    page-flags: define behavior of FS/IO-related flags on compound pages

    It seems we don't have compound page on FS/IO path currently.  Use
    NO_COMPOUND to catch if we have.

    The odd exception is PG_dirty: sound uses compound pages and maps
    them
    with PTEs.  NO_COMPOUND triggers VM_BUG_ON() in set_page_dirty() on
    handling shared fault.  Let's use HEAD for PG_dirty.

    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Christoph Lameter <cl@linux.com> 
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Jerome Marchand <jmarchan@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

:040000 040000 0d621460af1123de8fc33c881ae314c914725afc
b843f45fb2a1c2537e8c17946d3f8af512cab84d M      include
bisect run success

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Kevin Hilman]

Hi Ard,

Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:

[...]

> I think Will and I were both under the impression that this patch
>
> https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=kvm-bounce-page
>
> fixed the issue conclusively.

Nope, that branch is already part of linux-next, and linux-next still
fails to compile for 20+ defconfigs[1]

> Could you elaborate on the issue please? What is the error you are
> getting, and can you confirm that is is caused by ld choking on the
> linker script? If not, this is another error than the one we have been
> trying to fix

It's definitely not linker script related.

Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
here's the error when building for multi_v7_defconfig (full log
available[2]):

../mm/migrate.c: In function 'migrate_pages':
../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
this to your bugreport.
make[2]: *** [mm/migrate.o] Error 1
make[2]: Target `__build' not remade because of errors.
make[1]: *** [mm] Error 2

build bisect points to commit 21f992084aeb[3], but that doesn't revert
cleanly so I haven't got any further than that yet.

Kevin

[1] http://kernelci.org/build/next/kernel/next-20150331/
[2] http://storage.kernelci.org/next/next-20150331/arm-multi_v7_defconfig/build.log
[3] 21f992084aeb777675ba5f9c2dc6663e8a06e467 is the first bad commit

Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Wed Mar 25 13:02:28 2015 +1100

    page-flags: define behavior of FS/IO-related flags on compound pages

    It seems we don't have compound page on FS/IO path currently.  Use
    NO_COMPOUND to catch if we have.

    The odd exception is PG_dirty: sound uses compound pages and maps
    them
    with PTEs.  NO_COMPOUND triggers VM_BUG_ON() in set_page_dirty() on
    handling shared fault.  Let's use HEAD for PG_dirty.

    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Christoph Lameter <cl@linux.com> 
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Steve Capper <steve.capper@linaro.org>
    Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Jerome Marchand <jmarchan@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

:040000 040000 0d621460af1123de8fc33c881ae314c914725afc
b843f45fb2a1c2537e8c17946d3f8af512cab84d M      include
bisect run success

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

Hi Kevin,

On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote:
> Will Deacon <will.deacon@arm.com> writes:
> > On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> >> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> >> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> >> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> >> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> >> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> >> > >> > on next-20150324 :
> >> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> >> > >> > referenced in expression
> >> > >> > make: *** [vmlinux] Error 1
> >> > >>
> >> > >> Thanks, I am seeing that too.
> >> > >>
> >> > >> My armchair suggestion is that the following should be reverted.
> >> > >>
> >> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> >> > >
> >> > > Can you try again with the latest -next please? We've merged an additional
> >> > > patch aimed at sorting this out. Reverting isn't really an option, as
> >> > > there's an awful lot of code that depends on the bounce page removal.
> >> > 
> >> > Here are the kernelci.org -next results[1], if you click the build
> >> > status you can dig down into the build failures. next-20150326 has now
> >> > hit a compiler bug, Arnd mentioned he was looking into this issue.
> >> 
> >> I have confirmed that next-20150326 does not compile without
> >> the following reverted:
> >> 
> >> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> >> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
> >
> > Thanks for testing this and sorry for the continued breakage. Which
> > toolchain did you say you were using? Ard has some more patches trying to
> > fix this, but none of our toolchains seem to tickle the issue.
> 
> I've also tested on the default ARM toolchains available with ubuntu[1]
> 
> Are there any updates on this issue?

It's been fixed since the end of last week!

(see ARM: kvm: round HYP section to page size instead of log2 upper bound)

This was confirmed by both my testing and also Simon Horman, who reported
the initial breakage.

> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
> been broken for a week now, it is masking other types of issues that we
> can normally find via automated boot testing.

If you're referring to failures such as:

  http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log

Then that's not coming from the arm64 tree, and is a completely separate
issue from the one originally reported in this thread.

Will

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

Hi Kevin,

On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote:
> Will Deacon <will.deacon@arm.com> writes:
> > On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> >> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> >> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> >> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> >> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> >> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> >> > >> > on next-20150324 :
> >> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> >> > >> > referenced in expression
> >> > >> > make: *** [vmlinux] Error 1
> >> > >>
> >> > >> Thanks, I am seeing that too.
> >> > >>
> >> > >> My armchair suggestion is that the following should be reverted.
> >> > >>
> >> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> >> > >
> >> > > Can you try again with the latest -next please? We've merged an additional
> >> > > patch aimed at sorting this out. Reverting isn't really an option, as
> >> > > there's an awful lot of code that depends on the bounce page removal.
> >> > 
> >> > Here are the kernelci.org -next results[1], if you click the build
> >> > status you can dig down into the build failures. next-20150326 has now
> >> > hit a compiler bug, Arnd mentioned he was looking into this issue.
> >> 
> >> I have confirmed that next-20150326 does not compile without
> >> the following reverted:
> >> 
> >> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> >> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
> >
> > Thanks for testing this and sorry for the continued breakage. Which
> > toolchain did you say you were using? Ard has some more patches trying to
> > fix this, but none of our toolchains seem to tickle the issue.
> 
> I've also tested on the default ARM toolchains available with ubuntu[1]
> 
> Are there any updates on this issue?

It's been fixed since the end of last week!

(see ARM: kvm: round HYP section to page size instead of log2 upper bound)

This was confirmed by both my testing and also Simon Horman, who reported
the initial breakage.

> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
> been broken for a week now, it is masking other types of issues that we
> can normally find via automated boot testing.

If you're referring to failures such as:

  http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log

Then that's not coming from the arm64 tree, and is a completely separate
issue from the one originally reported in this thread.

Will

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Will Deacon]

Hi Kevin,

On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote:
> Will Deacon <will.deacon@arm.com> writes:
> > On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
> >> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> >> > On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
> >> > > On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
> >> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> >> > >> > I think we now have a new error: (seen with omap2plus_defconfig)
> >> > >> > on next-20150324 :
> >> > >> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> >> > >> > referenced in expression
> >> > >> > make: *** [vmlinux] Error 1
> >> > >>
> >> > >> Thanks, I am seeing that too.
> >> > >>
> >> > >> My armchair suggestion is that the following should be reverted.
> >> > >>
> >> > >> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> > >> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
> >> > >
> >> > > Can you try again with the latest -next please? We've merged an additional
> >> > > patch aimed at sorting this out. Reverting isn't really an option, as
> >> > > there's an awful lot of code that depends on the bounce page removal.
> >> > 
> >> > Here are the kernelci.org -next results[1], if you click the build
> >> > status you can dig down into the build failures. next-20150326 has now
> >> > hit a compiler bug, Arnd mentioned he was looking into this issue.
> >> 
> >> I have confirmed that next-20150326 does not compile without
> >> the following reverted:
> >> 
> >> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
> >> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
> >> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
> >
> > Thanks for testing this and sorry for the continued breakage. Which
> > toolchain did you say you were using? Ard has some more patches trying to
> > fix this, but none of our toolchains seem to tickle the issue.
> 
> I've also tested on the default ARM toolchains available with ubuntu[1]
> 
> Are there any updates on this issue?

It's been fixed since the end of last week!

(see ARM: kvm: round HYP section to page size instead of log2 upper bound)

This was confirmed by both my testing and also Simon Horman, who reported
the initial breakage.

> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
> been broken for a week now, it is masking other types of issues that we
> can normally find via automated boot testing.

If you're referring to failures such as:

  http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log

Then that's not coming from the arm64 tree, and is a completely separate
issue from the one originally reported in this thread.

Will

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3 (was: Re: Possible re

[Geert Uytterhoeven]

	Hi Kevin,

On Tue, 31 Mar 2015, Kevin Hilman wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> Nope, that branch is already part of linux-next, and linux-next still
> fails to compile for 20+ defconfigs[1]
> 
> > Could you elaborate on the issue please? What is the error you are
> > getting, and can you confirm that is is caused by ld choking on the
> > linker script? If not, this is another error than the one we have been
> > trying to fix
> 
> It's definitely not linker script related.
> 
> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
> here's the error when building for multi_v7_defconfig (full log
> available[2]):
> 
> ../mm/migrate.c: In function 'migrate_pages':
> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
> this to your bugreport.
> make[2]: *** [mm/migrate.o] Error 1
> make[2]: Target `__build' not remade because of errors.
> make[1]: *** [mm] Error 2
> 
> build bisect points to commit 21f992084aeb[3], but that doesn't revert
> cleanly so I haven't got any further than that yet.

I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
reproduce the ICE. I came up with the workaround below.
Does this work for you?

From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed, 1 Apr 2015 11:22:51 +0200
Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
 gcc 4.7.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :

    mm/migrate.c: In function ¡migrate_pages¢:
    mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
    Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
    make[1]: *** [mm/migrate.o] Error 1
    make: *** [mm/migrate.o] Error 2

Mark unmap_and_move() (which is used in a single place only) "noinline"
to work around this compiler bug.

Reported-by: Kevin Hilman <khilman@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 mm/migrate.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 114602a68111d809..98f8574456c2010c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -904,9 +904,10 @@ out:
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
-			unsigned long private, struct page *page, int force,
-			enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+				   free_page_t put_new_page,
+				   unsigned long private, struct page *page,
+				   int force, enum migrate_mode mode)
 {
 	int rc = 0;
 	int *result = NULL;
-- 
1.9.1


Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3 (was: Re: Possible regression in gcc 4.7.3 next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page")

[Geert Uytterhoeven]

	Hi Kevin,

On Tue, 31 Mar 2015, Kevin Hilman wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> Nope, that branch is already part of linux-next, and linux-next still
> fails to compile for 20+ defconfigs[1]
> 
> > Could you elaborate on the issue please? What is the error you are
> > getting, and can you confirm that is is caused by ld choking on the
> > linker script? If not, this is another error than the one we have been
> > trying to fix
> 
> It's definitely not linker script related.
> 
> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
> here's the error when building for multi_v7_defconfig (full log
> available[2]):
> 
> ../mm/migrate.c: In function 'migrate_pages':
> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
> this to your bugreport.
> make[2]: *** [mm/migrate.o] Error 1
> make[2]: Target `__build' not remade because of errors.
> make[1]: *** [mm] Error 2
> 
> build bisect points to commit 21f992084aeb[3], but that doesn't revert
> cleanly so I haven't got any further than that yet.

I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
reproduce the ICE. I came up with the workaround below.
Does this work for you?

>From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed, 1 Apr 2015 11:22:51 +0200
Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
 gcc 4.7.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :

    mm/migrate.c: In function ‘migrate_pages’:
    mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
    Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
    make[1]: *** [mm/migrate.o] Error 1
    make: *** [mm/migrate.o] Error 2

Mark unmap_and_move() (which is used in a single place only) "noinline"
to work around this compiler bug.

Reported-by: Kevin Hilman <khilman@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 mm/migrate.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 114602a68111d809..98f8574456c2010c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -904,9 +904,10 @@ out:
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
-			unsigned long private, struct page *page, int force,
-			enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+				   free_page_t put_new_page,
+				   unsigned long private, struct page *page,
+				   int force, enum migrate_mode mode)
 {
 	int rc = 0;
 	int *result = NULL;
-- 
1.9.1


Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3 (was: Re: Possible regression in gcc 4.7.3 next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page")

[Geert Uytterhoeven]

	Hi Kevin,

On Tue, 31 Mar 2015, Kevin Hilman wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> Nope, that branch is already part of linux-next, and linux-next still
> fails to compile for 20+ defconfigs[1]
> 
> > Could you elaborate on the issue please? What is the error you are
> > getting, and can you confirm that is is caused by ld choking on the
> > linker script? If not, this is another error than the one we have been
> > trying to fix
> 
> It's definitely not linker script related.
> 
> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
> here's the error when building for multi_v7_defconfig (full log
> available[2]):
> 
> ../mm/migrate.c: In function 'migrate_pages':
> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
> this to your bugreport.
> make[2]: *** [mm/migrate.o] Error 1
> make[2]: Target `__build' not remade because of errors.
> make[1]: *** [mm] Error 2
> 
> build bisect points to commit 21f992084aeb[3], but that doesn't revert
> cleanly so I haven't got any further than that yet.

I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
reproduce the ICE. I came up with the workaround below.
Does this work for you?

>From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed, 1 Apr 2015 11:22:51 +0200
Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
 gcc 4.7.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :

    mm/migrate.c: In function ‘migrate_pages’:
    mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
    Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
    make[1]: *** [mm/migrate.o] Error 1
    make: *** [mm/migrate.o] Error 2

Mark unmap_and_move() (which is used in a single place only) "noinline"
to work around this compiler bug.

Reported-by: Kevin Hilman <khilman@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 mm/migrate.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 114602a68111d809..98f8574456c2010c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -904,9 +904,10 @@ out:
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
-			unsigned long private, struct page *page, int force,
-			enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+				   free_page_t put_new_page,
+				   unsigned long private, struct page *page,
+				   int force, enum migrate_mode mode)
 {
 	int rc = 0;
 	int *result = NULL;
-- 
1.9.1


Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3 (was: Re: Possible regression in gcc 4.7.3 next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page")

[Geert Uytterhoeven]

	Hi Kevin,

On Tue, 31 Mar 2015, Kevin Hilman wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> Nope, that branch is already part of linux-next, and linux-next still
> fails to compile for 20+ defconfigs[1]
> 
> > Could you elaborate on the issue please? What is the error you are
> > getting, and can you confirm that is is caused by ld choking on the
> > linker script? If not, this is another error than the one we have been
> > trying to fix
> 
> It's definitely not linker script related.
> 
> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
> here's the error when building for multi_v7_defconfig (full log
> available[2]):
> 
> ../mm/migrate.c: In function 'migrate_pages':
> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
> this to your bugreport.
> make[2]: *** [mm/migrate.o] Error 1
> make[2]: Target `__build' not remade because of errors.
> make[1]: *** [mm] Error 2
> 
> build bisect points to commit 21f992084aeb[3], but that doesn't revert
> cleanly so I haven't got any further than that yet.

I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
reproduce the ICE. I came up with the workaround below.
Does this work for you?

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3 (was: Re: Possible regression in gcc 4.7.3 next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page")

[Geert Uytterhoeven]

	Hi Kevin,

On Tue, 31 Mar 2015, Kevin Hilman wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> Nope, that branch is already part of linux-next, and linux-next still
> fails to compile for 20+ defconfigs[1]
> 
> > Could you elaborate on the issue please? What is the error you are
> > getting, and can you confirm that is is caused by ld choking on the
> > linker script? If not, this is another error than the one we have been
> > trying to fix
> 
> It's definitely not linker script related.
> 
> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
> here's the error when building for multi_v7_defconfig (full log
> available[2]):
> 
> ../mm/migrate.c: In function 'migrate_pages':
> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
> this to your bugreport.
> make[2]: *** [mm/migrate.o] Error 1
> make[2]: Target `__build' not remade because of errors.
> make[1]: *** [mm] Error 2
> 
> build bisect points to commit 21f992084aeb[3], but that doesn't revert
> cleanly so I haven't got any further than that yet.

I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
reproduce the ICE. I came up with the workaround below.
Does this work for you?

>From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed, 1 Apr 2015 11:22:51 +0200
Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
 gcc 4.7.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :

    mm/migrate.c: In function ?migrate_pages?:
    mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
    Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
    make[1]: *** [mm/migrate.o] Error 1
    make: *** [mm/migrate.o] Error 2

Mark unmap_and_move() (which is used in a single place only) "noinline"
to work around this compiler bug.

Reported-by: Kevin Hilman <khilman@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 mm/migrate.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 114602a68111d809..98f8574456c2010c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -904,9 +904,10 @@ out:
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
-			unsigned long private, struct page *page, int force,
-			enum migrate_mode mode)
+static noinline int unmap_and_move(new_page_t get_new_page,
+				   free_page_t put_new_page,
+				   unsigned long private, struct page *page,
+				   int force, enum migrate_mode mode)
 {
 	int rc = 0;
 	int *result = NULL;
-- 
1.9.1


Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Marc Zyngier]

On 01/04/15 10:37, Geert Uytterhoeven wrote:
> 	Hi Kevin,
> 
> On Tue, 31 Mar 2015, Kevin Hilman wrote:
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>> Nope, that branch is already part of linux-next, and linux-next still
>> fails to compile for 20+ defconfigs[1]
>>
>>> Could you elaborate on the issue please? What is the error you are
>>> getting, and can you confirm that is is caused by ld choking on the
>>> linker script? If not, this is another error than the one we have been
>>> trying to fix
>>
>> It's definitely not linker script related.
>>
>> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
>> here's the error when building for multi_v7_defconfig (full log
>> available[2]):
>>
>> ../mm/migrate.c: In function 'migrate_pages':
>> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
>> this to your bugreport.
>> make[2]: *** [mm/migrate.o] Error 1
>> make[2]: Target `__build' not remade because of errors.
>> make[1]: *** [mm] Error 2
>>
>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
> 
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.
> Does this work for you?
> 
> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
> 
>     mm/migrate.c: In function ¡migrate_pages¢:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
> 
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
> 
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;
> 

Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
the parameters on the stack, which is not going to help performance
either (not that this would be useful on 32bit ARM anyway...).

Any chance you could make this dependent on some compiler detection
mechanism?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Marc Zyngier]

On 01/04/15 10:37, Geert Uytterhoeven wrote:
> 	Hi Kevin,
> 
> On Tue, 31 Mar 2015, Kevin Hilman wrote:
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>> Nope, that branch is already part of linux-next, and linux-next still
>> fails to compile for 20+ defconfigs[1]
>>
>>> Could you elaborate on the issue please? What is the error you are
>>> getting, and can you confirm that is is caused by ld choking on the
>>> linker script? If not, this is another error than the one we have been
>>> trying to fix
>>
>> It's definitely not linker script related.
>>
>> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
>> here's the error when building for multi_v7_defconfig (full log
>> available[2]):
>>
>> ../mm/migrate.c: In function 'migrate_pages':
>> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
>> this to your bugreport.
>> make[2]: *** [mm/migrate.o] Error 1
>> make[2]: Target `__build' not remade because of errors.
>> make[1]: *** [mm] Error 2
>>
>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
> 
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.
> Does this work for you?
> 
> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
> 
>     mm/migrate.c: In function ‘migrate_pages’:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
> 
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
> 
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;
> 

Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
the parameters on the stack, which is not going to help performance
either (not that this would be useful on 32bit ARM anyway...).

Any chance you could make this dependent on some compiler detection
mechanism?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Marc Zyngier]

On 01/04/15 10:37, Geert Uytterhoeven wrote:
> 	Hi Kevin,
> 
> On Tue, 31 Mar 2015, Kevin Hilman wrote:
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>> Nope, that branch is already part of linux-next, and linux-next still
>> fails to compile for 20+ defconfigs[1]
>>
>>> Could you elaborate on the issue please? What is the error you are
>>> getting, and can you confirm that is is caused by ld choking on the
>>> linker script? If not, this is another error than the one we have been
>>> trying to fix
>>
>> It's definitely not linker script related.
>>
>> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
>> here's the error when building for multi_v7_defconfig (full log
>> available[2]):
>>
>> ../mm/migrate.c: In function 'migrate_pages':
>> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
>> this to your bugreport.
>> make[2]: *** [mm/migrate.o] Error 1
>> make[2]: Target `__build' not remade because of errors.
>> make[1]: *** [mm] Error 2
>>
>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
> 
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.
> Does this work for you?
> 
> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
> 
>     mm/migrate.c: In function ‘migrate_pages’:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
> 
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
> 
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;
> 

Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
the parameters on the stack, which is not going to help performance
either (not that this would be useful on 32bit ARM anyway...).

Any chance you could make this dependent on some compiler detection
mechanism?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Marc Zyngier]

On 01/04/15 10:37, Geert Uytterhoeven wrote:
> 	Hi Kevin,
> 
> On Tue, 31 Mar 2015, Kevin Hilman wrote:
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>> Nope, that branch is already part of linux-next, and linux-next still
>> fails to compile for 20+ defconfigs[1]
>>
>>> Could you elaborate on the issue please? What is the error you are
>>> getting, and can you confirm that is is caused by ld choking on the
>>> linker script? If not, this is another error than the one we have been
>>> trying to fix
>>
>> It's definitely not linker script related.
>>
>> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
>> here's the error when building for multi_v7_defconfig (full log
>> available[2]):
>>
>> ../mm/migrate.c: In function 'migrate_pages':
>> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
>> this to your bugreport.
>> make[2]: *** [mm/migrate.o] Error 1
>> make[2]: Target `__build' not remade because of errors.
>> make[1]: *** [mm] Error 2
>>
>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
> 
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.
> Does this work for you?
> 
> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
> 
>     mm/migrate.c: In function !migrate_pagesc:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
> 
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
> 
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;
> 

Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
the parameters on the stack, which is not going to help performance
either (not that this would be useful on 32bit ARM anyway...).

Any chance you could make this dependent on some compiler detection
mechanism?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Marc Zyngier]

On 01/04/15 10:37, Geert Uytterhoeven wrote:
> 	Hi Kevin,
> 
> On Tue, 31 Mar 2015, Kevin Hilman wrote:
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>> Nope, that branch is already part of linux-next, and linux-next still
>> fails to compile for 20+ defconfigs[1]
>>
>>> Could you elaborate on the issue please? What is the error you are
>>> getting, and can you confirm that is is caused by ld choking on the
>>> linker script? If not, this is another error than the one we have been
>>> trying to fix
>>
>> It's definitely not linker script related.
>>
>> Using "arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3",
>> here's the error when building for multi_v7_defconfig (full log
>> available[2]):
>>
>> ../mm/migrate.c: In function 'migrate_pages':
>> ../mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13101
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>> Preprocessed source stored into /tmp/ccO1Nz1m.out file, please attach
>> this to your bugreport.
>> make[2]: *** [mm/migrate.o] Error 1
>> make[2]: Target `__build' not remade because of errors.
>> make[1]: *** [mm] Error 2
>>
>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
> 
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.
> Does this work for you?
> 
> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
> 
>     mm/migrate.c: In function ?migrate_pages?:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
> 
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
> 
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;
> 

Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
the parameters on the stack, which is not going to help performance
either (not that this would be useful on 32bit ARM anyway...).

Any chance you could make this dependent on some compiler detection
mechanism?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Nishanth Menon]

On 04/01/2015 03:58 AM, Will Deacon wrote:
> Hi Kevin,
> 
> On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>>> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>>>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>>>>> On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>>>>>> On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>>>>>>> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>>>>>>>> I think we now have a new error: (seen with omap2plus_defconfig)
>>>>>>>> on next-20150324 :
>>>>>>>> ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>>>>>>>> referenced in expression
>>>>>>>> make: *** [vmlinux] Error 1
>>>>>>>
>>>>>>> Thanks, I am seeing that too.
>>>>>>>
>>>>>>> My armchair suggestion is that the following should be reverted.
>>>>>>>
>>>>>>> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>>>>>> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>>>>>>
>>>>>> Can you try again with the latest -next please? We've merged an additional
>>>>>> patch aimed at sorting this out. Reverting isn't really an option, as
>>>>>> there's an awful lot of code that depends on the bounce page removal.
>>>>>
>>>>> Here are the kernelci.org -next results[1], if you click the build
>>>>> status you can dig down into the build failures. next-20150326 has now
>>>>> hit a compiler bug, Arnd mentioned he was looking into this issue.
>>>>
>>>> I have confirmed that next-20150326 does not compile without
>>>> the following reverted:
>>>>
>>>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>>>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>>>
>>> Thanks for testing this and sorry for the continued breakage. Which
>>> toolchain did you say you were using? Ard has some more patches trying to
>>> fix this, but none of our toolchains seem to tickle the issue.
>>
>> I've also tested on the default ARM toolchains available with ubuntu[1]
>>
>> Are there any updates on this issue?
> 
> It's been fixed since the end of last week!
> 

I can confirm that my tests have started functioning again (gcc 4.6)
https://github.com/nmenon/kernel-test-logs/tree/linux-next

-- 
Regards,
Nishanth Menon

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Nishanth Menon]

On 04/01/2015 03:58 AM, Will Deacon wrote:
> Hi Kevin,
> 
> On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>>> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>>>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>>>>> On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>>>>>> On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>>>>>>> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>>>>>>>> I think we now have a new error: (seen with omap2plus_defconfig)
>>>>>>>> on next-20150324 :
>>>>>>>> ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>>>>>>>> referenced in expression
>>>>>>>> make: *** [vmlinux] Error 1
>>>>>>>
>>>>>>> Thanks, I am seeing that too.
>>>>>>>
>>>>>>> My armchair suggestion is that the following should be reverted.
>>>>>>>
>>>>>>> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>>>>>> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>>>>>>
>>>>>> Can you try again with the latest -next please? We've merged an additional
>>>>>> patch aimed at sorting this out. Reverting isn't really an option, as
>>>>>> there's an awful lot of code that depends on the bounce page removal.
>>>>>
>>>>> Here are the kernelci.org -next results[1], if you click the build
>>>>> status you can dig down into the build failures. next-20150326 has now
>>>>> hit a compiler bug, Arnd mentioned he was looking into this issue.
>>>>
>>>> I have confirmed that next-20150326 does not compile without
>>>> the following reverted:
>>>>
>>>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>>>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>>>
>>> Thanks for testing this and sorry for the continued breakage. Which
>>> toolchain did you say you were using? Ard has some more patches trying to
>>> fix this, but none of our toolchains seem to tickle the issue.
>>
>> I've also tested on the default ARM toolchains available with ubuntu[1]
>>
>> Are there any updates on this issue?
> 
> It's been fixed since the end of last week!
> 

I can confirm that my tests have started functioning again (gcc 4.6)
https://github.com/nmenon/kernel-test-logs/tree/linux-next

-- 
Regards,
Nishanth Menon

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Nishanth Menon]

On 04/01/2015 03:58 AM, Will Deacon wrote:
> Hi Kevin,
> 
> On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote:
>> Will Deacon <will.deacon@arm.com> writes:
>>> On Fri, Mar 27, 2015 at 12:25:54AM +0000, Simon Horman wrote:
>>>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>>>>> On 26 March 2015 at 06:36, Will Deacon <will.deacon@arm.com> wrote:
>>>>>> On Thu, Mar 26, 2015 at 12:39:39AM +0000, Simon Horman wrote:
>>>>>>> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
>>>>>>>> I think we now have a new error: (seen with omap2plus_defconfig)
>>>>>>>> on next-20150324 :
>>>>>>>> ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
>>>>>>>> referenced in expression
>>>>>>>> make: *** [vmlinux] Error 1
>>>>>>>
>>>>>>> Thanks, I am seeing that too.
>>>>>>>
>>>>>>> My armchair suggestion is that the following should be reverted.
>>>>>>>
>>>>>>> e60a1fec44a2f ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>>>>>> 06f75a1f62000 ("ARM, arm64: kvm: get rid of the bounce page")
>>>>>>
>>>>>> Can you try again with the latest -next please? We've merged an additional
>>>>>> patch aimed at sorting this out. Reverting isn't really an option, as
>>>>>> there's an awful lot of code that depends on the bounce page removal.
>>>>>
>>>>> Here are the kernelci.org -next results[1], if you click the build
>>>>> status you can dig down into the build failures. next-20150326 has now
>>>>> hit a compiler bug, Arnd mentioned he was looking into this issue.
>>>>
>>>> I have confirmed that next-20150326 does not compile without
>>>> the following reverted:
>>>>
>>>> 12eb3e833961 ("ARM: kvm: assert on HYP section boundaries not actual code size")
>>>> e60a1fec44a2 ("ARM: kvm: implement replacement for ld's LOG2CEIL()")
>>>> 06f75a1f6200 ("ARM, arm64: kvm: get rid of the bounce page")
>>>
>>> Thanks for testing this and sorry for the continued breakage. Which
>>> toolchain did you say you were using? Ard has some more patches trying to
>>> fix this, but none of our toolchains seem to tickle the issue.
>>
>> I've also tested on the default ARM toolchains available with ubuntu[1]
>>
>> Are there any updates on this issue?
> 
> It's been fixed since the end of last week!
> 

I can confirm that my tests have started functioning again (gcc 4.6)
https://github.com/nmenon/kernel-test-logs/tree/linux-next

-- 
Regards,
Nishanth Menon

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Kevin Hilman]

Hi Will,

Will Deacon <will.deacon@arm.com> writes:

[...]

>> >
>> > Thanks for testing this and sorry for the continued breakage. Which
>> > toolchain did you say you were using? Ard has some more patches trying to
>> > fix this, but none of our toolchains seem to tickle the issue.
>> 
>> I've also tested on the default ARM toolchains available with ubuntu[1]
>> 
>> Are there any updates on this issue?
>
> It's been fixed since the end of last week!
>
> (see ARM: kvm: round HYP section to page size instead of log2 upper bound)
>
> This was confirmed by both my testing and also Simon Horman, who reported
> the initial breakage.
>
>> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
>> been broken for a week now, it is masking other types of issues that we
>> can normally find via automated boot testing.
>
> If you're referring to failures such as:
>
>   http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log

Yes, that's the one I'm trying to track down.

> Then that's not coming from the arm64 tree, and is a completely separate
> issue from the one originally reported in this thread.

Ugh, womehow I got wires crossed and thought they were related problems.
Looks like Geert now has a proposed fix for the issue I'm tracking.

Sorry for the noise,

Kevin

Re: Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Kevin Hilman]

Hi Will,

Will Deacon <will.deacon@arm.com> writes:

[...]

>> >
>> > Thanks for testing this and sorry for the continued breakage. Which
>> > toolchain did you say you were using? Ard has some more patches trying to
>> > fix this, but none of our toolchains seem to tickle the issue.
>> 
>> I've also tested on the default ARM toolchains available with ubuntu[1]
>> 
>> Are there any updates on this issue?
>
> It's been fixed since the end of last week!
>
> (see ARM: kvm: round HYP section to page size instead of log2 upper bound)
>
> This was confirmed by both my testing and also Simon Horman, who reported
> the initial breakage.
>
>> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
>> been broken for a week now, it is masking other types of issues that we
>> can normally find via automated boot testing.
>
> If you're referring to failures such as:
>
>   http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log

Yes, that's the one I'm trying to track down.

> Then that's not coming from the arm64 tree, and is a completely separate
> issue from the one originally reported in this thread.

Ugh, womehow I got wires crossed and thought they were related problems.
Looks like Geert now has a proposed fix for the issue I'm tracking.

Sorry for the noise,

Kevin

Possible regression in next-20150323 due to "ARM, arm64: kvm: get rid of the bounce page"

[Kevin Hilman]

Hi Will,

Will Deacon <will.deacon@arm.com> writes:

[...]

>> >
>> > Thanks for testing this and sorry for the continued breakage. Which
>> > toolchain did you say you were using? Ard has some more patches trying to
>> > fix this, but none of our toolchains seem to tickle the issue.
>> 
>> I've also tested on the default ARM toolchains available with ubuntu[1]
>> 
>> Are there any updates on this issue?
>
> It's been fixed since the end of last week!
>
> (see ARM: kvm: round HYP section to page size instead of log2 upper bound)
>
> This was confirmed by both my testing and also Simon Horman, who reported
> the initial breakage.
>
>> It ha broken most of the ARM defconfigs in linux-next[2], and since it's
>> been broken for a week now, it is masking other types of issues that we
>> can normally find via automated boot testing.
>
> If you're referring to failures such as:
>
>   http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log

Yes, that's the one I'm trying to track down.

> Then that's not coming from the arm64 tree, and is a completely separate
> issue from the one originally reported in this thread.

Ugh, womehow I got wires crossed and thought they were related problems.
Looks like Geert now has a proposed fix for the issue I'm tracking.

Sorry for the noise,

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

[...]

>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
>
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.

Awesome, thanks!

> Does this work for you?

Yes, that patch works well and fixes the regression. Build results for
all the defconfigs here:

   http://kernelci.org/build/khilman/kernel/v4.0-rc6-8294-g2ef3958cc27e/

and the remaining issues arent' realted to this ICE.

> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
>
>     mm/migrate.c: In function ‘migrate_pages’:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
>
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
>
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Tested-by: Kevin Hilman <khilman@linaro.org>

> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

[...]

>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
>
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.

Awesome, thanks!

> Does this work for you?

Yes, that patch works well and fixes the regression. Build results for
all the defconfigs here:

   http://kernelci.org/build/khilman/kernel/v4.0-rc6-8294-g2ef3958cc27e/

and the remaining issues arent' realted to this ICE.

> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
>
>     mm/migrate.c: In function ‘migrate_pages’:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
>
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
>
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Tested-by: Kevin Hilman <khilman@linaro.org>

> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

[...]

>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
>
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.

Awesome, thanks!

> Does this work for you?

Yes, that patch works well and fixes the regression. Build results for
all the defconfigs here:

   http://kernelci.org/build/khilman/kernel/v4.0-rc6-8294-g2ef3958cc27e/

and the remaining issues arent' realted to this ICE.

> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
>
>     mm/migrate.c: In function ‘migrate_pages’:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
>
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
>
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Tested-by: Kevin Hilman <khilman@linaro.org>

> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

[...]

>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
>
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.

Awesome, thanks!

> Does this work for you?

Yes, that patch works well and fixes the regression. Build results for
all the defconfigs here:

   http://kernelci.org/build/khilman/kernel/v4.0-rc6-8294-g2ef3958cc27e/

and the remaining issues arent' realted to this ICE.

> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
>
>     mm/migrate.c: In function ‘migrate_pages’:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
>
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
>
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Tested-by: Kevin Hilman <khilman@linaro.org>

> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

[...]

>> build bisect points to commit 21f992084aeb[3], but that doesn't revert
>> cleanly so I haven't got any further than that yet.
>
> I installed gcc-arm-linux-gnueabi (4:4.7.2-1 from Ubuntu 14.04 LTS) and could
> reproduce the ICE. I came up with the workaround below.

Awesome, thanks!

> Does this work for you?

Yes, that patch works well and fixes the regression. Build results for
all the defconfigs here:

   http://kernelci.org/build/khilman/kernel/v4.0-rc6-8294-g2ef3958cc27e/

and the remaining issues arent' realted to this ICE.

> From 7ebe83316eaf1952e55a76754ce7a5832e461b8c Mon Sep 17 00:00:00 2001
> From: Geert Uytterhoeven <geert+renesas@glider.be>
> Date: Wed, 1 Apr 2015 11:22:51 +0200
> Subject: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in
>  gcc 4.7.3
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> With gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) :
>
>     mm/migrate.c: In function ?migrate_pages?:
>     mm/migrate.c:1148:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:13500
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
>     Preprocessed source stored into /tmp/ccPoM1tr.out file, please attach this to your bugreport.
>     make[1]: *** [mm/migrate.o] Error 1
>     make: *** [mm/migrate.o] Error 2
>
> Mark unmap_and_move() (which is used in a single place only) "noinline"
> to work around this compiler bug.
>
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Tested-by: Kevin Hilman <khilman@linaro.org>

> ---
>  mm/migrate.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 114602a68111d809..98f8574456c2010c 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -904,9 +904,10 @@ out:
>   * Obtain the lock on page, remove all ptes and migrate the page
>   * to the newly allocated page in newpage.
>   */
> -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> -			unsigned long private, struct page *page, int force,
> -			enum migrate_mode mode)
> +static noinline int unmap_and_move(new_page_t get_new_page,
> +				   free_page_t put_new_page,
> +				   unsigned long private, struct page *page,
> +				   int force, enum migrate_mode mode)
>  {
>  	int rc = 0;
>  	int *result = NULL;

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:

> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> > -			unsigned long private, struct page *page, int force,
> > -			enum migrate_mode mode)
> > +static noinline int unmap_and_move(new_page_t get_new_page,
> > +				   free_page_t put_new_page,
> > +				   unsigned long private, struct page *page,
> > +				   int force, enum migrate_mode mode)
> >  {
> >  	int rc = 0;
> >  	int *result = NULL;
> > 
> 
> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
> the parameters on the stack, which is not going to help performance
> either (not that this would be useful on 32bit ARM anyway...).
> 
> Any chance you could make this dependent on some compiler detection
> mechanism?

With my arm compiler (gcc-4.4.4) the patch makes no difference -
unmap_and_move() isn't being inlined anyway.

How does this look?

Kevin, could you please retest?  I might have fat-fingered something...

--- a/mm/migrate.c~mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix
+++ a/mm/migrate.c
@@ -901,10 +901,20 @@ out:
 }
 
 /*
+ * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * it.
+ */
+#if GCC_VERSION = 40703 && defined(CONFIG_ARM)
+#define ICE_noinline noinline
+#else
+#define ICE_noinline
+#endif
+
+/*
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static noinline int unmap_and_move(new_page_t get_new_page,
+static ICE_noinline int unmap_and_move(new_page_t get_new_page,
 				   free_page_t put_new_page,
 				   unsigned long private, struct page *page,
 				   int force, enum migrate_mode mode)
_

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:

> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> > -			unsigned long private, struct page *page, int force,
> > -			enum migrate_mode mode)
> > +static noinline int unmap_and_move(new_page_t get_new_page,
> > +				   free_page_t put_new_page,
> > +				   unsigned long private, struct page *page,
> > +				   int force, enum migrate_mode mode)
> >  {
> >  	int rc = 0;
> >  	int *result = NULL;
> > 
> 
> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
> the parameters on the stack, which is not going to help performance
> either (not that this would be useful on 32bit ARM anyway...).
> 
> Any chance you could make this dependent on some compiler detection
> mechanism?

With my arm compiler (gcc-4.4.4) the patch makes no difference -
unmap_and_move() isn't being inlined anyway.

How does this look?

Kevin, could you please retest?  I might have fat-fingered something...

--- a/mm/migrate.c~mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix
+++ a/mm/migrate.c
@@ -901,10 +901,20 @@ out:
 }
 
 /*
+ * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * it.
+ */
+#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#define ICE_noinline noinline
+#else
+#define ICE_noinline
+#endif
+
+/*
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static noinline int unmap_and_move(new_page_t get_new_page,
+static ICE_noinline int unmap_and_move(new_page_t get_new_page,
 				   free_page_t put_new_page,
 				   unsigned long private, struct page *page,
 				   int force, enum migrate_mode mode)
_

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:

> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> > -			unsigned long private, struct page *page, int force,
> > -			enum migrate_mode mode)
> > +static noinline int unmap_and_move(new_page_t get_new_page,
> > +				   free_page_t put_new_page,
> > +				   unsigned long private, struct page *page,
> > +				   int force, enum migrate_mode mode)
> >  {
> >  	int rc = 0;
> >  	int *result = NULL;
> > 
> 
> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
> the parameters on the stack, which is not going to help performance
> either (not that this would be useful on 32bit ARM anyway...).
> 
> Any chance you could make this dependent on some compiler detection
> mechanism?

With my arm compiler (gcc-4.4.4) the patch makes no difference -
unmap_and_move() isn't being inlined anyway.

How does this look?

Kevin, could you please retest?  I might have fat-fingered something...

--- a/mm/migrate.c~mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix
+++ a/mm/migrate.c
@@ -901,10 +901,20 @@ out:
 }
 
 /*
+ * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * it.
+ */
+#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#define ICE_noinline noinline
+#else
+#define ICE_noinline
+#endif
+
+/*
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static noinline int unmap_and_move(new_page_t get_new_page,
+static ICE_noinline int unmap_and_move(new_page_t get_new_page,
 				   free_page_t put_new_page,
 				   unsigned long private, struct page *page,
 				   int force, enum migrate_mode mode)
_

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:

> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> > -			unsigned long private, struct page *page, int force,
> > -			enum migrate_mode mode)
> > +static noinline int unmap_and_move(new_page_t get_new_page,
> > +				   free_page_t put_new_page,
> > +				   unsigned long private, struct page *page,
> > +				   int force, enum migrate_mode mode)
> >  {
> >  	int rc = 0;
> >  	int *result = NULL;
> > 
> 
> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
> the parameters on the stack, which is not going to help performance
> either (not that this would be useful on 32bit ARM anyway...).
> 
> Any chance you could make this dependent on some compiler detection
> mechanism?

With my arm compiler (gcc-4.4.4) the patch makes no difference -
unmap_and_move() isn't being inlined anyway.

How does this look?

Kevin, could you please retest?  I might have fat-fingered something...

--- a/mm/migrate.c~mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix
+++ a/mm/migrate.c
@@ -901,10 +901,20 @@ out:
 }
 
 /*
+ * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * it.
+ */
+#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#define ICE_noinline noinline
+#else
+#define ICE_noinline
+#endif
+
+/*
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static noinline int unmap_and_move(new_page_t get_new_page,
+static ICE_noinline int unmap_and_move(new_page_t get_new_page,
 				   free_page_t put_new_page,
 				   unsigned long private, struct page *page,
 				   int force, enum migrate_mode mode)
_

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:

> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
> > -			unsigned long private, struct page *page, int force,
> > -			enum migrate_mode mode)
> > +static noinline int unmap_and_move(new_page_t get_new_page,
> > +				   free_page_t put_new_page,
> > +				   unsigned long private, struct page *page,
> > +				   int force, enum migrate_mode mode)
> >  {
> >  	int rc = 0;
> >  	int *result = NULL;
> > 
> 
> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
> the parameters on the stack, which is not going to help performance
> either (not that this would be useful on 32bit ARM anyway...).
> 
> Any chance you could make this dependent on some compiler detection
> mechanism?

With my arm compiler (gcc-4.4.4) the patch makes no difference -
unmap_and_move() isn't being inlined anyway.

How does this look?

Kevin, could you please retest?  I might have fat-fingered something...

--- a/mm/migrate.c~mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix
+++ a/mm/migrate.c
@@ -901,10 +901,20 @@ out:
 }
 
 /*
+ * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * it.
+ */
+#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#define ICE_noinline noinline
+#else
+#define ICE_noinline
+#endif
+
+/*
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
  */
-static noinline int unmap_and_move(new_page_t get_new_page,
+static ICE_noinline int unmap_and_move(new_page_t get_new_page,
 				   free_page_t put_new_page,
 				   unsigned long private, struct page *page,
 				   int force, enum migrate_mode mode)
_

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>
>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>> > -			unsigned long private, struct page *page, int force,
>> > -			enum migrate_mode mode)
>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>> > +				   free_page_t put_new_page,
>> > +				   unsigned long private, struct page *page,
>> > +				   int force, enum migrate_mode mode)
>> >  {
>> >  	int rc = 0;
>> >  	int *result = NULL;
>> > 
>> 
>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>> the parameters on the stack, which is not going to help performance
>> either (not that this would be useful on 32bit ARM anyway...).
>> 
>> Any chance you could make this dependent on some compiler detection
>> mechanism?
>
> With my arm compiler (gcc-4.4.4) the patch makes no difference -
> unmap_and_move() isn't being inlined anyway.
>
> How does this look?
>
> Kevin, could you please retest?  I might have fat-fingered something...

Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
However, I'm not sure how specific we can be on the versions.  

/me goes to test a few more compilers...   OK...

ICE: 4.7.1, 4.7.3, 4.8.3
OK: 4.6.3, 4.9.2, 4.9.3

The diff below[2] on top of yours compiles fine here and at least covers
the compilers I *know* to trigger the ICE.

Kevin


[1]
diff --git a/mm/migrate.c b/mm/migrate.c
index 25fd7f6291de..6e15ae3248e0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -901,10 +901,10 @@ out:
 }
 
 /*
- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
  * it.
  */
-#if GCC_VERSION = 40703 && defined(CONFIG_ARM)
+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
 #define ICE_noinline noinline
 #else
 #define ICE_noinline

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>
>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>> > -			unsigned long private, struct page *page, int force,
>> > -			enum migrate_mode mode)
>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>> > +				   free_page_t put_new_page,
>> > +				   unsigned long private, struct page *page,
>> > +				   int force, enum migrate_mode mode)
>> >  {
>> >  	int rc = 0;
>> >  	int *result = NULL;
>> > 
>> 
>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>> the parameters on the stack, which is not going to help performance
>> either (not that this would be useful on 32bit ARM anyway...).
>> 
>> Any chance you could make this dependent on some compiler detection
>> mechanism?
>
> With my arm compiler (gcc-4.4.4) the patch makes no difference -
> unmap_and_move() isn't being inlined anyway.
>
> How does this look?
>
> Kevin, could you please retest?  I might have fat-fingered something...

Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
However, I'm not sure how specific we can be on the versions.  

/me goes to test a few more compilers...   OK...

ICE: 4.7.1, 4.7.3, 4.8.3
OK: 4.6.3, 4.9.2, 4.9.3

The diff below[2] on top of yours compiles fine here and at least covers
the compilers I *know* to trigger the ICE.

Kevin


[1]
diff --git a/mm/migrate.c b/mm/migrate.c
index 25fd7f6291de..6e15ae3248e0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -901,10 +901,10 @@ out:
 }
 
 /*
- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
  * it.
  */
-#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
 #define ICE_noinline noinline
 #else
 #define ICE_noinline

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>
>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>> > -			unsigned long private, struct page *page, int force,
>> > -			enum migrate_mode mode)
>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>> > +				   free_page_t put_new_page,
>> > +				   unsigned long private, struct page *page,
>> > +				   int force, enum migrate_mode mode)
>> >  {
>> >  	int rc = 0;
>> >  	int *result = NULL;
>> > 
>> 
>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>> the parameters on the stack, which is not going to help performance
>> either (not that this would be useful on 32bit ARM anyway...).
>> 
>> Any chance you could make this dependent on some compiler detection
>> mechanism?
>
> With my arm compiler (gcc-4.4.4) the patch makes no difference -
> unmap_and_move() isn't being inlined anyway.
>
> How does this look?
>
> Kevin, could you please retest?  I might have fat-fingered something...

Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
However, I'm not sure how specific we can be on the versions.  

/me goes to test a few more compilers...   OK...

ICE: 4.7.1, 4.7.3, 4.8.3
OK: 4.6.3, 4.9.2, 4.9.3

The diff below[2] on top of yours compiles fine here and at least covers
the compilers I *know* to trigger the ICE.

Kevin


[1]
diff --git a/mm/migrate.c b/mm/migrate.c
index 25fd7f6291de..6e15ae3248e0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -901,10 +901,10 @@ out:
 }
 
 /*
- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
  * it.
  */
-#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
 #define ICE_noinline noinline
 #else
 #define ICE_noinline

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>
>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>> > -			unsigned long private, struct page *page, int force,
>> > -			enum migrate_mode mode)
>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>> > +				   free_page_t put_new_page,
>> > +				   unsigned long private, struct page *page,
>> > +				   int force, enum migrate_mode mode)
>> >  {
>> >  	int rc = 0;
>> >  	int *result = NULL;
>> > 
>> 
>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>> the parameters on the stack, which is not going to help performance
>> either (not that this would be useful on 32bit ARM anyway...).
>> 
>> Any chance you could make this dependent on some compiler detection
>> mechanism?
>
> With my arm compiler (gcc-4.4.4) the patch makes no difference -
> unmap_and_move() isn't being inlined anyway.
>
> How does this look?
>
> Kevin, could you please retest?  I might have fat-fingered something...

Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
However, I'm not sure how specific we can be on the versions.  

/me goes to test a few more compilers...   OK...

ICE: 4.7.1, 4.7.3, 4.8.3
OK: 4.6.3, 4.9.2, 4.9.3

The diff below[2] on top of yours compiles fine here and at least covers
the compilers I *know* to trigger the ICE.

Kevin


[1]
diff --git a/mm/migrate.c b/mm/migrate.c
index 25fd7f6291de..6e15ae3248e0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -901,10 +901,10 @@ out:
 }
 
 /*
- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
  * it.
  */
-#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
 #define ICE_noinline noinline
 #else
 #define ICE_noinline

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>
>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>> > -			unsigned long private, struct page *page, int force,
>> > -			enum migrate_mode mode)
>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>> > +				   free_page_t put_new_page,
>> > +				   unsigned long private, struct page *page,
>> > +				   int force, enum migrate_mode mode)
>> >  {
>> >  	int rc = 0;
>> >  	int *result = NULL;
>> > 
>> 
>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>> the parameters on the stack, which is not going to help performance
>> either (not that this would be useful on 32bit ARM anyway...).
>> 
>> Any chance you could make this dependent on some compiler detection
>> mechanism?
>
> With my arm compiler (gcc-4.4.4) the patch makes no difference -
> unmap_and_move() isn't being inlined anyway.
>
> How does this look?
>
> Kevin, could you please retest?  I might have fat-fingered something...

Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
However, I'm not sure how specific we can be on the versions.  

/me goes to test a few more compilers...   OK...

ICE: 4.7.1, 4.7.3, 4.8.3
OK: 4.6.3, 4.9.2, 4.9.3

The diff below[2] on top of yours compiles fine here and at least covers
the compilers I *know* to trigger the ICE.

Kevin


[1]
diff --git a/mm/migrate.c b/mm/migrate.c
index 25fd7f6291de..6e15ae3248e0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -901,10 +901,10 @@ out:
 }
 
 /*
- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
  * it.
  */
-#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
 #define ICE_noinline noinline
 #else
 #define ICE_noinline

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Russell King - ARM Linux]

On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.  
> 
> /me goes to test a few more compilers...   OK...
> 
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
> 
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
-next (only mainline + my tree + arm-soc) and it hasn't shown a problem
yet.

I think we need to ask the question: is the bug in stock GCC or Linaro
GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Russell King - ARM Linux]

On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.  
> 
> /me goes to test a few more compilers...   OK...
> 
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
> 
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
-next (only mainline + my tree + arm-soc) and it hasn't shown a problem
yet.

I think we need to ask the question: is the bug in stock GCC or Linaro
GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Russell King - ARM Linux]

On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.  
> 
> /me goes to test a few more compilers...   OK...
> 
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
> 
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
-next (only mainline + my tree + arm-soc) and it hasn't shown a problem
yet.

I think we need to ask the question: is the bug in stock GCC or Linaro
GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Russell King - ARM Linux]

On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.  
> 
> /me goes to test a few more compilers...   OK...
> 
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
> 
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
-next (only mainline + my tree + arm-soc) and it hasn't shown a problem
yet.

I think we need to ask the question: is the bug in stock GCC or Linaro
GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Russell King - ARM Linux]

On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.  
> 
> /me goes to test a few more compilers...   OK...
> 
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
> 
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
-next (only mainline + my tree + arm-soc) and it hasn't shown a problem
yet.

I think we need to ask the question: is the bug in stock GCC or Linaro
GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Geert Uytterhoeven]

Hi Russell,

On Wed, Apr 1, 2015 at 11:59 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
> Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
> -next (only mainline + my tree + arm-soc) and it hasn't shown a problem
> yet.

Mainline doesn't fail.

> I think we need to ask the question: is the bug in stock GCC or Linaro
> GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

Can you please try -next (e.g. next-20150320)?

make bockw_defconfig
make mm/migrate.o

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Geert Uytterhoeven]

Hi Russell,

On Wed, Apr 1, 2015 at 11:59 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
> Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
> -next (only mainline + my tree + arm-soc) and it hasn't shown a problem
> yet.

Mainline doesn't fail.

> I think we need to ask the question: is the bug in stock GCC or Linaro
> GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

Can you please try -next (e.g. next-20150320)?

make bockw_defconfig
make mm/migrate.o

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Geert Uytterhoeven]

Hi Russell,

On Wed, Apr 1, 2015 at 11:59 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
> Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
> -next (only mainline + my tree + arm-soc) and it hasn't shown a problem
> yet.

Mainline doesn't fail.

> I think we need to ask the question: is the bug in stock GCC or Linaro
> GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

Can you please try -next (e.g. next-20150320)?

make bockw_defconfig
make mm/migrate.o

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Geert Uytterhoeven]

Hi Russell,

On Wed, Apr 1, 2015 at 11:59 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
> Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
> -next (only mainline + my tree + arm-soc) and it hasn't shown a problem
> yet.

Mainline doesn't fail.

> I think we need to ask the question: is the bug in stock GCC or Linaro
> GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

Can you please try -next (e.g. next-20150320)?

make bockw_defconfig
make mm/migrate.o

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -			unsigned long private, struct page *page, int force,
>>> > -			enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +				   free_page_t put_new_page,
>>> > +				   unsigned long private, struct page *page,
>>> > +				   int force, enum migrate_mode mode)
>>> >  {
>>> >  	int rc = 0;
>>> >  	int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
>Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>However, I'm not sure how specific we can be on the versions.
>
>/me goes to test a few more compilers...   OK...
>
>ICE: 4.7.1, 4.7.3, 4.8.3
>OK: 4.6.3, 4.9.2, 4.9.3
>
>The diff below[2] on top of yours compiles fine here and at least covers
>the compilers I *know* to trigger the ICE.

I see ICE on 
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4

>
>Kevin
>
>
>[1]
>diff --git a/mm/migrate.c b/mm/migrate.c
>index 25fd7f6291de..6e15ae3248e0 100644
>--- a/mm/migrate.c
>+++ b/mm/migrate.c
>@@ -901,10 +901,10 @@ out:
> }
>
> /*
>- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
>+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
>  * it.
>  */
>-#if GCC_VERSION = 40703 && defined(CONFIG_ARM)
>+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
> #define ICE_noinline noinline
> #else
> #define ICE_noinline
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -			unsigned long private, struct page *page, int force,
>>> > -			enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +				   free_page_t put_new_page,
>>> > +				   unsigned long private, struct page *page,
>>> > +				   int force, enum migrate_mode mode)
>>> >  {
>>> >  	int rc = 0;
>>> >  	int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
>Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>However, I'm not sure how specific we can be on the versions.
>
>/me goes to test a few more compilers...   OK...
>
>ICE: 4.7.1, 4.7.3, 4.8.3
>OK: 4.6.3, 4.9.2, 4.9.3
>
>The diff below[2] on top of yours compiles fine here and at least covers
>the compilers I *know* to trigger the ICE.

I see ICE on 
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4

>
>Kevin
>
>
>[1]
>diff --git a/mm/migrate.c b/mm/migrate.c
>index 25fd7f6291de..6e15ae3248e0 100644
>--- a/mm/migrate.c
>+++ b/mm/migrate.c
>@@ -901,10 +901,10 @@ out:
> }
>
> /*
>- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
>+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
>  * it.
>  */
>-#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
>+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
> #define ICE_noinline noinline
> #else
> #define ICE_noinline
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -			unsigned long private, struct page *page, int force,
>>> > -			enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +				   free_page_t put_new_page,
>>> > +				   unsigned long private, struct page *page,
>>> > +				   int force, enum migrate_mode mode)
>>> >  {
>>> >  	int rc = 0;
>>> >  	int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
>Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>However, I'm not sure how specific we can be on the versions.
>
>/me goes to test a few more compilers...   OK...
>
>ICE: 4.7.1, 4.7.3, 4.8.3
>OK: 4.6.3, 4.9.2, 4.9.3
>
>The diff below[2] on top of yours compiles fine here and at least covers
>the compilers I *know* to trigger the ICE.

I see ICE on 
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4

>
>Kevin
>
>
>[1]
>diff --git a/mm/migrate.c b/mm/migrate.c
>index 25fd7f6291de..6e15ae3248e0 100644
>--- a/mm/migrate.c
>+++ b/mm/migrate.c
>@@ -901,10 +901,10 @@ out:
> }
>
> /*
>- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
>+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
>  * it.
>  */
>-#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
>+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
> #define ICE_noinline noinline
> #else
> #define ICE_noinline
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -			unsigned long private, struct page *page, int force,
>>> > -			enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +				   free_page_t put_new_page,
>>> > +				   unsigned long private, struct page *page,
>>> > +				   int force, enum migrate_mode mode)
>>> >  {
>>> >  	int rc = 0;
>>> >  	int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
>Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>However, I'm not sure how specific we can be on the versions.
>
>/me goes to test a few more compilers...   OK...
>
>ICE: 4.7.1, 4.7.3, 4.8.3
>OK: 4.6.3, 4.9.2, 4.9.3
>
>The diff below[2] on top of yours compiles fine here and at least covers
>the compilers I *know* to trigger the ICE.

I see ICE on 
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4

>
>Kevin
>
>
>[1]
>diff --git a/mm/migrate.c b/mm/migrate.c
>index 25fd7f6291de..6e15ae3248e0 100644
>--- a/mm/migrate.c
>+++ b/mm/migrate.c
>@@ -901,10 +901,10 @@ out:
> }
>
> /*
>- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
>+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
>  * it.
>  */
>-#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
>+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
> #define ICE_noinline noinline
> #else
> #define ICE_noinline
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -			unsigned long private, struct page *page, int force,
>>> > -			enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +				   free_page_t put_new_page,
>>> > +				   unsigned long private, struct page *page,
>>> > +				   int force, enum migrate_mode mode)
>>> >  {
>>> >  	int rc = 0;
>>> >  	int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
>Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>However, I'm not sure how specific we can be on the versions.
>
>/me goes to test a few more compilers...   OK...
>
>ICE: 4.7.1, 4.7.3, 4.8.3
>OK: 4.6.3, 4.9.2, 4.9.3
>
>The diff below[2] on top of yours compiles fine here and at least covers
>the compilers I *know* to trigger the ICE.

I see ICE on 
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4

>
>Kevin
>
>
>[1]
>diff --git a/mm/migrate.c b/mm/migrate.c
>index 25fd7f6291de..6e15ae3248e0 100644
>--- a/mm/migrate.c
>+++ b/mm/migrate.c
>@@ -901,10 +901,10 @@ out:
> }
>
> /*
>- * gcc-4.7.3 on arm gets an ICE when inlining unmap_and_move().  Work around
>+ * gcc 4.7 and 4.8 on arm gets an ICE when inlining unmap_and_move().  Work around
>  * it.
>  */
>-#if GCC_VERSION == 40703 && defined(CONFIG_ARM)
>+#if (GCC_VERSION >= 40700 && GCC_VERSION < 40900) && defined(CONFIG_ARM)
> #define ICE_noinline noinline
> #else
> #define ICE_noinline
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>>
>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>> > put_new_page,
>>>> > -                     unsigned long private, struct page *page, int
>>>> > force,
>>>> > -                     enum migrate_mode mode)
>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>> > +                                free_page_t put_new_page,
>>>> > +                                unsigned long private, struct page
>>>> > *page,
>>>> > +                                int force, enum migrate_mode mode)
>>>> >  {
>>>> >       int rc = 0;
>>>> >       int *result = NULL;
>>>> >
>>>>
>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>> the parameters on the stack, which is not going to help performance
>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>
>>>> Any chance you could make this dependent on some compiler detection
>>>> mechanism?
>>>
>>>
>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>> unmap_and_move() isn't being inlined anyway.
>>>
>>> How does this look?
>>>
>>> Kevin, could you please retest?  I might have fat-fingered something...
>>
>>
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
>
> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>

Thanks for checking.  I'm assuming my patch fixes it for your since
that should catch any 4.7.x compiler.

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>>
>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>> > put_new_page,
>>>> > -                     unsigned long private, struct page *page, int
>>>> > force,
>>>> > -                     enum migrate_mode mode)
>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>> > +                                free_page_t put_new_page,
>>>> > +                                unsigned long private, struct page
>>>> > *page,
>>>> > +                                int force, enum migrate_mode mode)
>>>> >  {
>>>> >       int rc = 0;
>>>> >       int *result = NULL;
>>>> >
>>>>
>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>> the parameters on the stack, which is not going to help performance
>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>
>>>> Any chance you could make this dependent on some compiler detection
>>>> mechanism?
>>>
>>>
>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>> unmap_and_move() isn't being inlined anyway.
>>>
>>> How does this look?
>>>
>>> Kevin, could you please retest?  I might have fat-fingered something...
>>
>>
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
>
> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>

Thanks for checking.  I'm assuming my patch fixes it for your since
that should catch any 4.7.x compiler.

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>>
>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>> > put_new_page,
>>>> > -                     unsigned long private, struct page *page, int
>>>> > force,
>>>> > -                     enum migrate_mode mode)
>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>> > +                                free_page_t put_new_page,
>>>> > +                                unsigned long private, struct page
>>>> > *page,
>>>> > +                                int force, enum migrate_mode mode)
>>>> >  {
>>>> >       int rc = 0;
>>>> >       int *result = NULL;
>>>> >
>>>>
>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>> the parameters on the stack, which is not going to help performance
>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>
>>>> Any chance you could make this dependent on some compiler detection
>>>> mechanism?
>>>
>>>
>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>> unmap_and_move() isn't being inlined anyway.
>>>
>>> How does this look?
>>>
>>> Kevin, could you please retest?  I might have fat-fingered something...
>>
>>
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
>
> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>

Thanks for checking.  I'm assuming my patch fixes it for your since
that should catch any 4.7.x compiler.

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>>
>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>> > put_new_page,
>>>> > -                     unsigned long private, struct page *page, int
>>>> > force,
>>>> > -                     enum migrate_mode mode)
>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>> > +                                free_page_t put_new_page,
>>>> > +                                unsigned long private, struct page
>>>> > *page,
>>>> > +                                int force, enum migrate_mode mode)
>>>> >  {
>>>> >       int rc = 0;
>>>> >       int *result = NULL;
>>>> >
>>>>
>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>> the parameters on the stack, which is not going to help performance
>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>
>>>> Any chance you could make this dependent on some compiler detection
>>>> mechanism?
>>>
>>>
>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>> unmap_and_move() isn't being inlined anyway.
>>>
>>> How does this look?
>>>
>>> Kevin, could you please retest?  I might have fat-fingered something...
>>
>>
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
>
> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>

Thanks for checking.  I'm assuming my patch fixes it for your since
that should catch any 4.7.x compiler.

Kevin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>>
>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>> > put_new_page,
>>>> > -                     unsigned long private, struct page *page, int
>>>> > force,
>>>> > -                     enum migrate_mode mode)
>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>> > +                                free_page_t put_new_page,
>>>> > +                                unsigned long private, struct page
>>>> > *page,
>>>> > +                                int force, enum migrate_mode mode)
>>>> >  {
>>>> >       int rc = 0;
>>>> >       int *result = NULL;
>>>> >
>>>>
>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>> the parameters on the stack, which is not going to help performance
>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>
>>>> Any chance you could make this dependent on some compiler detection
>>>> mechanism?
>>>
>>>
>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>> unmap_and_move() isn't being inlined anyway.
>>>
>>> How does this look?
>>>
>>> Kevin, could you please retest?  I might have fat-fingered something...
>>
>>
>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>> However, I'm not sure how specific we can be on the versions.
>>
>> /me goes to test a few more compilers...   OK...
>>
>> ICE: 4.7.1, 4.7.3, 4.8.3
>> OK: 4.6.3, 4.9.2, 4.9.3
>>
>> The diff below[2] on top of yours compiles fine here and at least covers
>> the compilers I *know* to trigger the ICE.
>
>
> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>

Thanks for checking.  I'm assuming my patch fixes it for your since
that should catch any 4.7.x compiler.

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Thu, Apr 02 2015 at 15:12 -0600, Kevin Hilman wrote:
>On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>>
>>> Andrew Morton <akpm@linux-foundation.org> writes:
>>>
>>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>
>>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>>> > put_new_page,
>>>>> > -                     unsigned long private, struct page *page, int
>>>>> > force,
>>>>> > -                     enum migrate_mode mode)
>>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>>> > +                                free_page_t put_new_page,
>>>>> > +                                unsigned long private, struct page
>>>>> > *page,
>>>>> > +                                int force, enum migrate_mode mode)
>>>>> >  {
>>>>> >       int rc = 0;
>>>>> >       int *result = NULL;
>>>>> >
>>>>>
>>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>>> the parameters on the stack, which is not going to help performance
>>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>>
>>>>> Any chance you could make this dependent on some compiler detection
>>>>> mechanism?
>>>>
>>>>
>>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>>> unmap_and_move() isn't being inlined anyway.
>>>>
>>>> How does this look?
>>>>
>>>> Kevin, could you please retest?  I might have fat-fingered something...
>>>
>>>
>>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>>> However, I'm not sure how specific we can be on the versions.
>>>
>>> /me goes to test a few more compilers...   OK...
>>>
>>> ICE: 4.7.1, 4.7.3, 4.8.3
>>> OK: 4.6.3, 4.9.2, 4.9.3
>>>
>>> The diff below[2] on top of yours compiles fine here and at least covers
>>> the compilers I *know* to trigger the ICE.
>>
>>
>> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>>
>
>Thanks for checking.  I'm assuming my patch fixes it for your since
>that should catch any 4.7.x compiler.

Yes, thank you. This fixes it on 4.7.4
>
>Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Thu, Apr 02 2015 at 15:12 -0600, Kevin Hilman wrote:
>On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>>
>>> Andrew Morton <akpm@linux-foundation.org> writes:
>>>
>>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>
>>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>>> > put_new_page,
>>>>> > -                     unsigned long private, struct page *page, int
>>>>> > force,
>>>>> > -                     enum migrate_mode mode)
>>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>>> > +                                free_page_t put_new_page,
>>>>> > +                                unsigned long private, struct page
>>>>> > *page,
>>>>> > +                                int force, enum migrate_mode mode)
>>>>> >  {
>>>>> >       int rc = 0;
>>>>> >       int *result = NULL;
>>>>> >
>>>>>
>>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>>> the parameters on the stack, which is not going to help performance
>>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>>
>>>>> Any chance you could make this dependent on some compiler detection
>>>>> mechanism?
>>>>
>>>>
>>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>>> unmap_and_move() isn't being inlined anyway.
>>>>
>>>> How does this look?
>>>>
>>>> Kevin, could you please retest?  I might have fat-fingered something...
>>>
>>>
>>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>>> However, I'm not sure how specific we can be on the versions.
>>>
>>> /me goes to test a few more compilers...   OK...
>>>
>>> ICE: 4.7.1, 4.7.3, 4.8.3
>>> OK: 4.6.3, 4.9.2, 4.9.3
>>>
>>> The diff below[2] on top of yours compiles fine here and at least covers
>>> the compilers I *know* to trigger the ICE.
>>
>>
>> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>>
>
>Thanks for checking.  I'm assuming my patch fixes it for your since
>that should catch any 4.7.x compiler.

Yes, thank you. This fixes it on 4.7.4
>
>Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Thu, Apr 02 2015 at 15:12 -0600, Kevin Hilman wrote:
>On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>>
>>> Andrew Morton <akpm@linux-foundation.org> writes:
>>>
>>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>
>>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>>> > put_new_page,
>>>>> > -                     unsigned long private, struct page *page, int
>>>>> > force,
>>>>> > -                     enum migrate_mode mode)
>>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>>> > +                                free_page_t put_new_page,
>>>>> > +                                unsigned long private, struct page
>>>>> > *page,
>>>>> > +                                int force, enum migrate_mode mode)
>>>>> >  {
>>>>> >       int rc = 0;
>>>>> >       int *result = NULL;
>>>>> >
>>>>>
>>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>>> the parameters on the stack, which is not going to help performance
>>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>>
>>>>> Any chance you could make this dependent on some compiler detection
>>>>> mechanism?
>>>>
>>>>
>>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>>> unmap_and_move() isn't being inlined anyway.
>>>>
>>>> How does this look?
>>>>
>>>> Kevin, could you please retest?  I might have fat-fingered something...
>>>
>>>
>>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>>> However, I'm not sure how specific we can be on the versions.
>>>
>>> /me goes to test a few more compilers...   OK...
>>>
>>> ICE: 4.7.1, 4.7.3, 4.8.3
>>> OK: 4.6.3, 4.9.2, 4.9.3
>>>
>>> The diff below[2] on top of yours compiles fine here and at least covers
>>> the compilers I *know* to trigger the ICE.
>>
>>
>> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>>
>
>Thanks for checking.  I'm assuming my patch fixes it for your since
>that should catch any 4.7.x compiler.

Yes, thank you. This fixes it on 4.7.4
>
>Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Thu, Apr 02 2015 at 15:12 -0600, Kevin Hilman wrote:
>On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>>
>>> Andrew Morton <akpm@linux-foundation.org> writes:
>>>
>>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>
>>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>>> > put_new_page,
>>>>> > -                     unsigned long private, struct page *page, int
>>>>> > force,
>>>>> > -                     enum migrate_mode mode)
>>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>>> > +                                free_page_t put_new_page,
>>>>> > +                                unsigned long private, struct page
>>>>> > *page,
>>>>> > +                                int force, enum migrate_mode mode)
>>>>> >  {
>>>>> >       int rc = 0;
>>>>> >       int *result = NULL;
>>>>> >
>>>>>
>>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>>> the parameters on the stack, which is not going to help performance
>>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>>
>>>>> Any chance you could make this dependent on some compiler detection
>>>>> mechanism?
>>>>
>>>>
>>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>>> unmap_and_move() isn't being inlined anyway.
>>>>
>>>> How does this look?
>>>>
>>>> Kevin, could you please retest?  I might have fat-fingered something...
>>>
>>>
>>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>>> However, I'm not sure how specific we can be on the versions.
>>>
>>> /me goes to test a few more compilers...   OK...
>>>
>>> ICE: 4.7.1, 4.7.3, 4.8.3
>>> OK: 4.6.3, 4.9.2, 4.9.3
>>>
>>> The diff below[2] on top of yours compiles fine here and at least covers
>>> the compilers I *know* to trigger the ICE.
>>
>>
>> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>>
>
>Thanks for checking.  I'm assuming my patch fixes it for your since
>that should catch any 4.7.x compiler.

Yes, thank you. This fixes it on 4.7.4
>
>Kevin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Lina Iyer]

On Thu, Apr 02 2015 at 15:12 -0600, Kevin Hilman wrote:
>On Thu, Apr 2, 2015 at 12:12 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> On Wed, Apr 01 2015 at 15:57 -0600, Kevin Hilman wrote:
>>>
>>> Andrew Morton <akpm@linux-foundation.org> writes:
>>>
>>>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>
>>>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t
>>>>> > put_new_page,
>>>>> > -                     unsigned long private, struct page *page, int
>>>>> > force,
>>>>> > -                     enum migrate_mode mode)
>>>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>>>> > +                                free_page_t put_new_page,
>>>>> > +                                unsigned long private, struct page
>>>>> > *page,
>>>>> > +                                int force, enum migrate_mode mode)
>>>>> >  {
>>>>> >       int rc = 0;
>>>>> >       int *result = NULL;
>>>>> >
>>>>>
>>>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>>>> the parameters on the stack, which is not going to help performance
>>>>> either (not that this would be useful on 32bit ARM anyway...).
>>>>>
>>>>> Any chance you could make this dependent on some compiler detection
>>>>> mechanism?
>>>>
>>>>
>>>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>>>> unmap_and_move() isn't being inlined anyway.
>>>>
>>>> How does this look?
>>>>
>>>> Kevin, could you please retest?  I might have fat-fingered something...
>>>
>>>
>>> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
>>> However, I'm not sure how specific we can be on the versions.
>>>
>>> /me goes to test a few more compilers...   OK...
>>>
>>> ICE: 4.7.1, 4.7.3, 4.8.3
>>> OK: 4.6.3, 4.9.2, 4.9.3
>>>
>>> The diff below[2] on top of yours compiles fine here and at least covers
>>> the compilers I *know* to trigger the ICE.
>>
>>
>> I see ICE on arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4
>>
>
>Thanks for checking.  I'm assuming my patch fixes it for your since
>that should catch any 4.7.x compiler.

Yes, thank you. This fixes it on 4.7.4
>
>Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Hi Andrew,

On Wed, Apr 1, 2015 at 2:54 PM, Kevin Hilman <khilman@kernel.org> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -                  unsigned long private, struct page *page, int force,
>>> > -                  enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +                             free_page_t put_new_page,
>>> > +                             unsigned long private, struct page *page,
>>> > +                             int force, enum migrate_mode mode)
>>> >  {
>>> >    int rc = 0;
>>> >    int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.
>
> /me goes to test a few more compilers...   OK...
>
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
>
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

I see my fix in your mmots since last Thurs (4/2), but it's not in
mmotm (last updated today) so today's linux-next still has the ICE for
anything other than gcc-4.7.3.   Just checking to see when you plan to
update mmotm.

Thanks,

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Hi Andrew,

On Wed, Apr 1, 2015 at 2:54 PM, Kevin Hilman <khilman@kernel.org> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -                  unsigned long private, struct page *page, int force,
>>> > -                  enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +                             free_page_t put_new_page,
>>> > +                             unsigned long private, struct page *page,
>>> > +                             int force, enum migrate_mode mode)
>>> >  {
>>> >    int rc = 0;
>>> >    int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.
>
> /me goes to test a few more compilers...   OK...
>
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
>
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

I see my fix in your mmots since last Thurs (4/2), but it's not in
mmotm (last updated today) so today's linux-next still has the ICE for
anything other than gcc-4.7.3.   Just checking to see when you plan to
update mmotm.

Thanks,

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Hi Andrew,

On Wed, Apr 1, 2015 at 2:54 PM, Kevin Hilman <khilman@kernel.org> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -                  unsigned long private, struct page *page, int force,
>>> > -                  enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +                             free_page_t put_new_page,
>>> > +                             unsigned long private, struct page *page,
>>> > +                             int force, enum migrate_mode mode)
>>> >  {
>>> >    int rc = 0;
>>> >    int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.
>
> /me goes to test a few more compilers...   OK...
>
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
>
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

I see my fix in your mmots since last Thurs (4/2), but it's not in
mmotm (last updated today) so today's linux-next still has the ICE for
anything other than gcc-4.7.3.   Just checking to see when you plan to
update mmotm.

Thanks,

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Hi Andrew,

On Wed, Apr 1, 2015 at 2:54 PM, Kevin Hilman <khilman@kernel.org> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -                  unsigned long private, struct page *page, int force,
>>> > -                  enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +                             free_page_t put_new_page,
>>> > +                             unsigned long private, struct page *page,
>>> > +                             int force, enum migrate_mode mode)
>>> >  {
>>> >    int rc = 0;
>>> >    int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.
>
> /me goes to test a few more compilers...   OK...
>
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
>
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

I see my fix in your mmots since last Thurs (4/2), but it's not in
mmotm (last updated today) so today's linux-next still has the ICE for
anything other than gcc-4.7.3.   Just checking to see when you plan to
update mmotm.

Thanks,

Kevin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Hi Andrew,

On Wed, Apr 1, 2015 at 2:54 PM, Kevin Hilman <khilman@kernel.org> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
>> On Wed, 01 Apr 2015 10:47:49 +0100 Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>>> > -static int unmap_and_move(new_page_t get_new_page, free_page_t put_new_page,
>>> > -                  unsigned long private, struct page *page, int force,
>>> > -                  enum migrate_mode mode)
>>> > +static noinline int unmap_and_move(new_page_t get_new_page,
>>> > +                             free_page_t put_new_page,
>>> > +                             unsigned long private, struct page *page,
>>> > +                             int force, enum migrate_mode mode)
>>> >  {
>>> >    int rc = 0;
>>> >    int *result = NULL;
>>> >
>>>
>>> Ouch. That's really ugly. And on 32bit ARM, we end-up spilling half of
>>> the parameters on the stack, which is not going to help performance
>>> either (not that this would be useful on 32bit ARM anyway...).
>>>
>>> Any chance you could make this dependent on some compiler detection
>>> mechanism?
>>
>> With my arm compiler (gcc-4.4.4) the patch makes no difference -
>> unmap_and_move() isn't being inlined anyway.
>>
>> How does this look?
>>
>> Kevin, could you please retest?  I might have fat-fingered something...
>
> Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
> However, I'm not sure how specific we can be on the versions.
>
> /me goes to test a few more compilers...   OK...
>
> ICE: 4.7.1, 4.7.3, 4.8.3
> OK: 4.6.3, 4.9.2, 4.9.3
>
> The diff below[2] on top of yours compiles fine here and at least covers
> the compilers I *know* to trigger the ICE.

I see my fix in your mmots since last Thurs (4/2), but it's not in
mmotm (last updated today) so today's linux-next still has the ICE for
anything other than gcc-4.7.3.   Just checking to see when you plan to
update mmotm.

Thanks,

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> > The diff below[2] on top of yours compiles fine here and at least covers
> > the compilers I *know* to trigger the ICE.
> 
> I see my fix in your mmots since last Thurs (4/2), but it's not in
> mmotm (last updated today) so today's linux-next still has the ICE for
> anything other than gcc-4.7.3.   Just checking to see when you plan to
> update mmotm.

It should all be there today?

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> > The diff below[2] on top of yours compiles fine here and at least covers
> > the compilers I *know* to trigger the ICE.
> 
> I see my fix in your mmots since last Thurs (4/2), but it's not in
> mmotm (last updated today) so today's linux-next still has the ICE for
> anything other than gcc-4.7.3.   Just checking to see when you plan to
> update mmotm.

It should all be there today?

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> > The diff below[2] on top of yours compiles fine here and at least covers
> > the compilers I *know* to trigger the ICE.
> 
> I see my fix in your mmots since last Thurs (4/2), but it's not in
> mmotm (last updated today) so today's linux-next still has the ICE for
> anything other than gcc-4.7.3.   Just checking to see when you plan to
> update mmotm.

It should all be there today?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> > The diff below[2] on top of yours compiles fine here and at least covers
> > the compilers I *know* to trigger the ICE.
> 
> I see my fix in your mmots since last Thurs (4/2), but it's not in
> mmotm (last updated today) so today's linux-next still has the ICE for
> anything other than gcc-4.7.3.   Just checking to see when you plan to
> update mmotm.

It should all be there today?

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> > The diff below[2] on top of yours compiles fine here and at least covers
>> > the compilers I *know* to trigger the ICE.
>> 
>> I see my fix in your mmots since last Thurs (4/2), but it's not in
>> mmotm (last updated today) so today's linux-next still has the ICE for
>> anything other than gcc-4.7.3.   Just checking to see when you plan to
>> update mmotm.
>
> It should all be there today?

Nope.  

In mmotm, only the original patch plus your first fix is there:

$ curl -sO http://www.ozlabs.org/~akpm/mmotm/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r----- akpm/eng       1838 2015-04-01 14:41 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r----- akpm/eng       1309 2015-04-01 14:41 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch

but in mmots, the additional ptch from me, plus another comment fixup
from you are also there:

$ curl -sO http://www.ozlabs.org/~akpm/mmots/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r----- akpm/eng       1882 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r----- akpm/eng       1271 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch
-rw-r----- akpm/eng       1382 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix.patch
-rw-r----- akpm/eng        968 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix-fix.patch


Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> > The diff below[2] on top of yours compiles fine here and at least covers
>> > the compilers I *know* to trigger the ICE.
>> 
>> I see my fix in your mmots since last Thurs (4/2), but it's not in
>> mmotm (last updated today) so today's linux-next still has the ICE for
>> anything other than gcc-4.7.3.   Just checking to see when you plan to
>> update mmotm.
>
> It should all be there today?

Nope.  

In mmotm, only the original patch plus your first fix is there:

$ curl -sO http://www.ozlabs.org/~akpm/mmotm/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r----- akpm/eng       1838 2015-04-01 14:41 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r----- akpm/eng       1309 2015-04-01 14:41 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch

but in mmots, the additional ptch from me, plus another comment fixup
from you are also there:

$ curl -sO http://www.ozlabs.org/~akpm/mmots/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r----- akpm/eng       1882 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r----- akpm/eng       1271 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch
-rw-r----- akpm/eng       1382 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix.patch
-rw-r----- akpm/eng        968 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix-fix.patch


Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> > The diff below[2] on top of yours compiles fine here and at least covers
>> > the compilers I *know* to trigger the ICE.
>> 
>> I see my fix in your mmots since last Thurs (4/2), but it's not in
>> mmotm (last updated today) so today's linux-next still has the ICE for
>> anything other than gcc-4.7.3.   Just checking to see when you plan to
>> update mmotm.
>
> It should all be there today?

Nope.  

In mmotm, only the original patch plus your first fix is there:

$ curl -sO http://www.ozlabs.org/~akpm/mmotm/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r----- akpm/eng       1838 2015-04-01 14:41 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r----- akpm/eng       1309 2015-04-01 14:41 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch

but in mmots, the additional ptch from me, plus another comment fixup
from you are also there:

$ curl -sO http://www.ozlabs.org/~akpm/mmots/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r----- akpm/eng       1882 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r----- akpm/eng       1271 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch
-rw-r----- akpm/eng       1382 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix.patch
-rw-r----- akpm/eng        968 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix-fix.patch


Kevin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> > The diff below[2] on top of yours compiles fine here and at least covers
>> > the compilers I *know* to trigger the ICE.
>> 
>> I see my fix in your mmots since last Thurs (4/2), but it's not in
>> mmotm (last updated today) so today's linux-next still has the ICE for
>> anything other than gcc-4.7.3.   Just checking to see when you plan to
>> update mmotm.
>
> It should all be there today?

Nope.  

In mmotm, only the original patch plus your first fix is there:

$ curl -sO http://www.ozlabs.org/~akpm/mmotm/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r----- akpm/eng       1838 2015-04-01 14:41 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r----- akpm/eng       1309 2015-04-01 14:41 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch

but in mmots, the additional ptch from me, plus another comment fixup
from you are also there:

$ curl -sO http://www.ozlabs.org/~akpm/mmots/broken-out.tar.gz
$ tar -tavf broken-out.tar.gz |grep gcc-473
-rw-r----- akpm/eng       1882 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473.patch
-rw-r----- akpm/eng       1271 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix.patch
-rw-r----- akpm/eng       1382 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix.patch
-rw-r----- akpm/eng        968 2015-04-06 16:24 broken-out/mm-migrate-mark-unmap_and_move-noinline-to-avoid-ice-in-gcc-473-fix-fix-fix.patch


Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
> >
> >> > The diff below[2] on top of yours compiles fine here and at least covers
> >> > the compilers I *know* to trigger the ICE.
> >> 
> >> I see my fix in your mmots since last Thurs (4/2), but it's not in
> >> mmotm (last updated today) so today's linux-next still has the ICE for
> >> anything other than gcc-4.7.3.   Just checking to see when you plan to
> >> update mmotm.
> >
> > It should all be there today?
> 
> Nope.  

huh, I swear I did an mmotm yesterday.

Let me see if I can sort out the watchdog mess and produce something
releasable...

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
> >
> >> > The diff below[2] on top of yours compiles fine here and at least covers
> >> > the compilers I *know* to trigger the ICE.
> >> 
> >> I see my fix in your mmots since last Thurs (4/2), but it's not in
> >> mmotm (last updated today) so today's linux-next still has the ICE for
> >> anything other than gcc-4.7.3.   Just checking to see when you plan to
> >> update mmotm.
> >
> > It should all be there today?
> 
> Nope.  

huh, I swear I did an mmotm yesterday.

Let me see if I can sort out the watchdog mess and produce something
releasable...

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
> >
> >> > The diff below[2] on top of yours compiles fine here and at least covers
> >> > the compilers I *know* to trigger the ICE.
> >> 
> >> I see my fix in your mmots since last Thurs (4/2), but it's not in
> >> mmotm (last updated today) so today's linux-next still has the ICE for
> >> anything other than gcc-4.7.3.   Just checking to see when you plan to
> >> update mmotm.
> >
> > It should all be there today?
> 
> Nope.  

huh, I swear I did an mmotm yesterday.

Let me see if I can sort out the watchdog mess and produce something
releasable...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
> >
> >> > The diff below[2] on top of yours compiles fine here and at least covers
> >> > the compilers I *know* to trigger the ICE.
> >> 
> >> I see my fix in your mmots since last Thurs (4/2), but it's not in
> >> mmotm (last updated today) so today's linux-next still has the ICE for
> >> anything other than gcc-4.7.3.   Just checking to see when you plan to
> >> update mmotm.
> >
> > It should all be there today?
> 
> Nope.  

huh, I swear I did an mmotm yesterday.

Let me see if I can sort out the watchdog mess and produce something
releasable...

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>> 
>> > On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>> >
>> >> > The diff below[2] on top of yours compiles fine here and at least covers
>> >> > the compilers I *know* to trigger the ICE.
>> >> 
>> >> I see my fix in your mmots since last Thurs (4/2), but it's not in
>> >> mmotm (last updated today) so today's linux-next still has the ICE for
>> >> anything other than gcc-4.7.3.   Just checking to see when you plan to
>> >> update mmotm.
>> >
>> > It should all be there today?
>> 
>> Nope.  
>
> huh, I swear I did an mmotm yesterday.

Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
did.  That's why I was confused why the gcc-473 patches from mmots aren't
there.

> Let me see if I can sort out the watchdog mess and produce something
> releasable...

OK, thanks.

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>> 
>> > On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>> >
>> >> > The diff below[2] on top of yours compiles fine here and at least covers
>> >> > the compilers I *know* to trigger the ICE.
>> >> 
>> >> I see my fix in your mmots since last Thurs (4/2), but it's not in
>> >> mmotm (last updated today) so today's linux-next still has the ICE for
>> >> anything other than gcc-4.7.3.   Just checking to see when you plan to
>> >> update mmotm.
>> >
>> > It should all be there today?
>> 
>> Nope.  
>
> huh, I swear I did an mmotm yesterday.

Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
did.  That's why I was confused why the gcc-473 patches from mmots aren't
there.

> Let me see if I can sort out the watchdog mess and produce something
> releasable...

OK, thanks.

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>> 
>> > On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>> >
>> >> > The diff below[2] on top of yours compiles fine here and at least covers
>> >> > the compilers I *know* to trigger the ICE.
>> >> 
>> >> I see my fix in your mmots since last Thurs (4/2), but it's not in
>> >> mmotm (last updated today) so today's linux-next still has the ICE for
>> >> anything other than gcc-4.7.3.   Just checking to see when you plan to
>> >> update mmotm.
>> >
>> > It should all be there today?
>> 
>> Nope.  
>
> huh, I swear I did an mmotm yesterday.

Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
did.  That's why I was confused why the gcc-473 patches from mmots aren't
there.

> Let me see if I can sort out the watchdog mess and produce something
> releasable...

OK, thanks.

Kevin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 07 Apr 2015 15:41:32 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>> 
>> > On Tue, 7 Apr 2015 10:57:52 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>> >
>> >> > The diff below[2] on top of yours compiles fine here and at least covers
>> >> > the compilers I *know* to trigger the ICE.
>> >> 
>> >> I see my fix in your mmots since last Thurs (4/2), but it's not in
>> >> mmotm (last updated today) so today's linux-next still has the ICE for
>> >> anything other than gcc-4.7.3.   Just checking to see when you plan to
>> >> update mmotm.
>> >
>> > It should all be there today?
>> 
>> Nope.  
>
> huh, I swear I did an mmotm yesterday.

Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
did.  That's why I was confused why the gcc-473 patches from mmots aren't
there.

> Let me see if I can sort out the watchdog mess and produce something
> releasable...

OK, thanks.

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> >> > It should all be there today?
> >> 
> >> Nope.  
> >
> > huh, I swear I did an mmotm yesterday.
> 
> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
> did.  That's why I was confused why the gcc-473 patches from mmots aren't
> there.

Things look a bit better now.

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> >> > It should all be there today?
> >> 
> >> Nope.  
> >
> > huh, I swear I did an mmotm yesterday.
> 
> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
> did.  That's why I was confused why the gcc-473 patches from mmots aren't
> there.

Things look a bit better now.

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> >> > It should all be there today?
> >> 
> >> Nope.  
> >
> > huh, I swear I did an mmotm yesterday.
> 
> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
> did.  That's why I was confused why the gcc-473 patches from mmots aren't
> there.

Things look a bit better now.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Andrew Morton]

On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman <khilman@kernel.org> wrote:

> >> > It should all be there today?
> >> 
> >> Nope.  
> >
> > huh, I swear I did an mmotm yesterday.
> 
> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
> did.  That's why I was confused why the gcc-473 patches from mmots aren't
> there.

Things look a bit better now.

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> >> > It should all be there today?
>> >> 
>> >> Nope.  
>> >
>> > huh, I swear I did an mmotm yesterday.
>> 
>> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
>> did.  That's why I was confused why the gcc-473 patches from mmots aren't
>> there.
>
> Things look a bit better now.

Yup, I can confirm all 4 patches are there now.  Things should be in
good shape for the next -next.

Thanks,

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> >> > It should all be there today?
>> >> 
>> >> Nope.  
>> >
>> > huh, I swear I did an mmotm yesterday.
>> 
>> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
>> did.  That's why I was confused why the gcc-473 patches from mmots aren't
>> there.
>
> Things look a bit better now.

Yup, I can confirm all 4 patches are there now.  Things should be in
good shape for the next -next.

Thanks,

Kevin

Re: [PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> >> > It should all be there today?
>> >> 
>> >> Nope.  
>> >
>> > huh, I swear I did an mmotm yesterday.
>> 
>> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
>> did.  That's why I was confused why the gcc-473 patches from mmots aren't
>> there.
>
> Things look a bit better now.

Yup, I can confirm all 4 patches are there now.  Things should be in
good shape for the next -next.

Thanks,

Kevin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm/migrate: Mark unmap_and_move() "noinline" to avoid ICE in gcc 4.7.3

[Kevin Hilman]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 07 Apr 2015 16:27:44 -0700 Kevin Hilman <khilman@kernel.org> wrote:
>
>> >> > It should all be there today?
>> >> 
>> >> Nope.  
>> >
>> > huh, I swear I did an mmotm yesterday.
>> 
>> Well, based on the timestamp of the mmotm dir on ozlabs, it appears you
>> did.  That's why I was confused why the gcc-473 patches from mmots aren't
>> there.
>
> Things look a bit better now.

Yup, I can confirm all 4 patches are there now.  Things should be in
good shape for the next -next.

Thanks,

Kevin