Build failures in v3.10-stable-queue, v3.14-stable-queue

Build failures in v3.10-stable-queue, v3.14-stable-queue

[Guenter Roeck]

arm64 (v3.10):

arch/arm64/mm/mmu.c: In function ‘paging_init’:
arch/arm64/mm/mmu.c:352:11: error: macro "dsb" passed 1 arguments, but takes just 0
   dsb(ishst);

Culprit is 'arm64: mm: ensure that the zero page is visible to the page table walker'.
dsb() doesn't have an argument in v3.10. Copying Will Deacon for advice.

---
arm64, i386, m68k, mips, powerpc, sparc, xtensa (v3.14):

drivers/net/vxlan.c: In function ‘vxlan_newlink’:
include/net/vxlan.h:30:28: error: ‘VXLAN_F_UDP_ZERO_CSUM6_RX’ undeclared (first use in this function)
  #define VXLAN_F_RCV_FLAGS  VXLAN_F_UDP_ZERO_CSUM6_RX

Culprit is 'vxlan: fix test which detect duplicate vxlan iface'. VXLAN_F_UDP_ZERO_CSUM6_RX
does not exist in v3.14. Copying Nicolas Dichtel for advice.

---
mn10300 (v3.10, v3.14):

kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
ipc/util.c:609:2: error: 'old_uid_t' undeclared

and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
check v3.14.y). Let me know if you need a backport.

---
openrisc (v3.10, v3.14):

fs/stat.c:230:2: error: 'old_uid_t' undeclared

and many others.

Requires 04ea1e91f856 ("openrisc: fix CONFIG_UID16 setting").

Guenter

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue

[Will Deacon]

On Wed, Jan 27, 2016 at 04:22:39AM -0800, Guenter Roeck wrote:
> arm64 (v3.10):
> 
> arch/arm64/mm/mmu.c: In function ‘paging_init’:
> arch/arm64/mm/mmu.c:352:11: error: macro "dsb" passed 1 arguments, but takes just 0
>   dsb(ishst);
> 
> Culprit is 'arm64: mm: ensure that the zero page is visible to the page table walker'.
> dsb() doesn't have an argument in v3.10. Copying Will Deacon for advice.

You can just used dsb() instead of dsb(ishst).

Will

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue

[Nicolas Dichtel]

Le 27/01/2016 13:22, Guenter Roeck a écrit :
[snip]
> drivers/net/vxlan.c: In function ‘vxlan_newlink’:
> include/net/vxlan.h:30:28: error: ‘VXLAN_F_UDP_ZERO_CSUM6_RX’ undeclared (first
> use in this function)
>   #define VXLAN_F_RCV_FLAGS  VXLAN_F_UDP_ZERO_CSUM6_RX
>
> Culprit is 'vxlan: fix test which detect duplicate vxlan iface'.
> VXLAN_F_UDP_ZERO_CSUM6_RX
> does not exist in v3.14. Copying Nicolas Dichtel for advice.
The "Fixes" tag in the original patch indicates that the bug was introduced by
commit 1c51a9159dde ("vxlan: fix race caused by dropping rtnl_unlock"), ie in
linux 3.11.
I don't see a backport of this patch in the 3.10 branch, so I think that we
can drop this patch for the 3.10 branch.

About the 3.14 branch: VXLAN_F_UDP_ZERO_CSUM6_RX has been introduce in 3.16 by
commit 359a0ea9875e ("vxlan: Add support for UDP checksums (v4 sending, v6 zero
csums)").
I think that we can just drop the test against the flags.


Regards,
Nicolas

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue

[Greg Kroah-Hartman]

On Wed, Jan 27, 2016 at 04:22:39AM -0800, Guenter Roeck wrote:
> ---
> arm64, i386, m68k, mips, powerpc, sparc, xtensa (v3.14):
> 
> drivers/net/vxlan.c: In function ‘vxlan_newlink’:
> include/net/vxlan.h:30:28: error: ‘VXLAN_F_UDP_ZERO_CSUM6_RX’ undeclared (first use in this function)
>  #define VXLAN_F_RCV_FLAGS  VXLAN_F_UDP_ZERO_CSUM6_RX
> 
> Culprit is 'vxlan: fix test which detect duplicate vxlan iface'. VXLAN_F_UDP_ZERO_CSUM6_RX
> does not exist in v3.14. Copying Nicolas Dichtel for advice.

I've dropped this patch from the 3.14 queue now, thanks.

greg k-h

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue (+4.1, 4.3, 4.4)

[Guenter Roeck]

On 01/27/2016 04:22 AM, Guenter Roeck wrote:
[ ... ]

> ---
> mn10300 (v3.10, v3.14):
>
> kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
> kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
> ipc/util.c:609:2: error: 'old_uid_t' undeclared
>
> and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
> to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
> check v3.14.y). Let me know if you need a backport.
>
4.1 and 4.3 are also affected by this problem.

---
arm64 (4.1, 4.3):

allmodconfig core dumps (oops). I'll need to look into that one.

arm64 (4.3, 4,4):

qemu emulation fails (is stuck completely). This also happens in mainline.
Culprit is 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'.
The fix is not yet in mainline, only in -next.

Guenter

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue (+4.1, 4.3, 4.4)

[Will Deacon]

On Wed, Jan 27, 2016 at 08:34:33AM -0800, Guenter Roeck wrote:
> On 01/27/2016 04:22 AM, Guenter Roeck wrote:
> [ ... ]
> 
> >---
> >mn10300 (v3.10, v3.14):
> >
> >kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
> >kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
> >ipc/util.c:609:2: error: 'old_uid_t' undeclared
> >
> >and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
> >to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
> >check v3.14.y). Let me know if you need a backport.
> >
> 4.1 and 4.3 are also affected by this problem.
> 
> ---
> arm64 (4.1, 4.3):
> 
> allmodconfig core dumps (oops). I'll need to look into that one.
> 
> arm64 (4.3, 4,4):
> 
> qemu emulation fails (is stuck completely). This also happens in mainline.
> Culprit is 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'.
> The fix is not yet in mainline, only in -next.

I've got the fix sitting in the arm64 fixes branch and will send the pull
later today.

Will

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue (+4.1, 4.3, 4.4)

[Guenter Roeck]

On 01/27/2016 08:34 AM, Guenter Roeck wrote:
> On 01/27/2016 04:22 AM, Guenter Roeck wrote:
> [ ... ]
>
>> ---
>> mn10300 (v3.10, v3.14):
>>
>> kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
>> kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
>> ipc/util.c:609:2: error: 'old_uid_t' undeclared
>>
>> and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
>> to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
>> check v3.14.y). Let me know if you need a backport.
>>
> 4.1 and 4.3 are also affected by this problem.
>
> ---
> arm64 (4.1, 4.3):
>
> allmodconfig core dumps (oops). I'll need to look into that one.
>

Two patches are culprits here:

- 'recordmcount: arm64: Replace the ignored mcount call into nop' causes the crash.
   It is not the C compiler. Maybe some other patch to recordmcount is missing.

- 'arm64: mm: use correct mapping granularity under DEBUG_RODATA' uses SWAPPER_BLOCK_SIZE
   which is not defined in 4.3. This causes a build failure in 4.3 after reverting the above.
   I didn't check 4.1.

Guenter

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue

[Greg Kroah-Hartman]

On Wed, Jan 27, 2016 at 04:22:39AM -0800, Guenter Roeck wrote:
> openrisc (v3.10, v3.14):
> 
> fs/stat.c:230:2: error: 'old_uid_t' undeclared
> 
> and many others.
> 
> Requires 04ea1e91f856 ("openrisc: fix CONFIG_UID16 setting").

Now fixed, thanks.

greg k-h

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue

[Greg Kroah-Hartman]

On Wed, Jan 27, 2016 at 12:31:26PM +0000, Will Deacon wrote:
> On Wed, Jan 27, 2016 at 04:22:39AM -0800, Guenter Roeck wrote:
> > arm64 (v3.10):
> > 
> > arch/arm64/mm/mmu.c: In function ‘paging_init’:
> > arch/arm64/mm/mmu.c:352:11: error: macro "dsb" passed 1 arguments, but takes just 0
> >   dsb(ishst);
> > 
> > Culprit is 'arm64: mm: ensure that the zero page is visible to the page table walker'.
> > dsb() doesn't have an argument in v3.10. Copying Will Deacon for advice.
> 
> You can just used dsb() instead of dsb(ishst).

I should have caught that, you said so in the comments.  Now fixed up,
thanks.

greg k-h

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue

[Greg Kroah-Hartman]

On Wed, Jan 27, 2016 at 04:22:39AM -0800, Guenter Roeck wrote:
> ---
> mn10300 (v3.10, v3.14):
> 
> kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
> kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
> ipc/util.c:609:2: error: 'old_uid_t' undeclared
> 
> and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
> to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
> check v3.14.y). Let me know if you need a backport.

Now queued up for all of these, the conflict was easy to fix, thanks.

greg k-h

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue (+4.1, 4.3, 4.4)

[Greg Kroah-Hartman]

On Wed, Jan 27, 2016 at 09:16:12AM -0800, Guenter Roeck wrote:
> On 01/27/2016 08:34 AM, Guenter Roeck wrote:
> >On 01/27/2016 04:22 AM, Guenter Roeck wrote:
> >[ ... ]
> >
> >>---
> >>mn10300 (v3.10, v3.14):
> >>
> >>kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
> >>kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
> >>ipc/util.c:609:2: error: 'old_uid_t' undeclared
> >>
> >>and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
> >>to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
> >>check v3.14.y). Let me know if you need a backport.
> >>
> >4.1 and 4.3 are also affected by this problem.
> >
> >---
> >arm64 (4.1, 4.3):
> >
> >allmodconfig core dumps (oops). I'll need to look into that one.
> >
> 
> Two patches are culprits here:
> 
> - 'recordmcount: arm64: Replace the ignored mcount call into nop' causes the crash.
>   It is not the C compiler. Maybe some other patch to recordmcount is missing.
> 
> - 'arm64: mm: use correct mapping granularity under DEBUG_RODATA' uses SWAPPER_BLOCK_SIZE
>   which is not defined in 4.3. This causes a build failure in 4.3 after reverting the above.
>   I didn't check 4.1.

Ok, as I have no idea here, and don't have an arm64 system to do
anything with (i.e. test), I'll just leave this alone until someone who
does care about the architecture comes along with a fix :)

thanks,

greg k-h

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue (+4.1, 4.3, 4.4)

[Will Deacon]

On Wed, Jan 27, 2016 at 09:49:36AM -0800, Greg Kroah-Hartman wrote:
> On Wed, Jan 27, 2016 at 09:16:12AM -0800, Guenter Roeck wrote:
> > On 01/27/2016 08:34 AM, Guenter Roeck wrote:
> > >On 01/27/2016 04:22 AM, Guenter Roeck wrote:
> > >[ ... ]
> > >
> > >>---
> > >>mn10300 (v3.10, v3.14):
> > >>
> > >>kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
> > >>kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
> > >>ipc/util.c:609:2: error: 'old_uid_t' undeclared
> > >>
> > >>and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
> > >>to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
> > >>check v3.14.y). Let me know if you need a backport.
> > >>
> > >4.1 and 4.3 are also affected by this problem.
> > >
> > >---
> > >arm64 (4.1, 4.3):
> > >
> > >allmodconfig core dumps (oops). I'll need to look into that one.
> > >
> > 
> > Two patches are culprits here:
> > 
> > - 'recordmcount: arm64: Replace the ignored mcount call into nop' causes the crash.
> >   It is not the C compiler. Maybe some other patch to recordmcount is missing.
> > 
> > - 'arm64: mm: use correct mapping granularity under DEBUG_RODATA' uses SWAPPER_BLOCK_SIZE
> >   which is not defined in 4.3. This causes a build failure in 4.3 after reverting the above.
> >   I didn't check 4.1.
> 
> Ok, as I have no idea here, and don't have an arm64 system to do
> anything with (i.e. test), I'll just leave this alone until someone who
> does care about the architecture comes along with a fix :)

We'll take a look...

Will

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue (+4.1, 4.3, 4.4)

[Sudeep Holla]

On 27/01/16 17:49, Greg Kroah-Hartman wrote:
> On Wed, Jan 27, 2016 at 09:16:12AM -0800, Guenter Roeck wrote:
>> On 01/27/2016 08:34 AM, Guenter Roeck wrote:
>>> On 01/27/2016 04:22 AM, Guenter Roeck wrote:
>>> [ ... ]
>>>
>>>> ---
>>>> mn10300 (v3.10, v3.14):
>>>>
>>>> kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
>>>> kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
>>>> ipc/util.c:609:2: error: 'old_uid_t' undeclared
>>>>
>>>> and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
>>>> to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
>>>> check v3.14.y). Let me know if you need a backport.
>>>>
>>> 4.1 and 4.3 are also affected by this problem.
>>>
>>> ---
>>> arm64 (4.1, 4.3):
>>>
>>> allmodconfig core dumps (oops). I'll need to look into that one.
>>>
>>
>> Two patches are culprits here:
>>
>> - 'recordmcount: arm64: Replace the ignored mcount call into nop' causes the crash.
>>    It is not the C compiler. Maybe some other patch to recordmcount is missing.
>>

This bug is due the endianness mix at-least in my build setup and commit
c84da8b9ad37 ("recordmcount: Fix endianness handling bug for
nop_mcount") seems to fix it for me.

It's already marked for stable and I see that there are quite a few
patches queued for stable in scripts/recordmcount.[ch]. But I see Greg
has already pointed this out in the NOTE in his initial "[PATCH 4.1 
000/127] 4.1.17-stable review" email.

>> - 'arm64: mm: use correct mapping granularity under DEBUG_RODATA' uses SWAPPER_BLOCK_SIZE
>>    which is not defined in 4.3. This causes a build failure in 4.3 after reverting the above.
>>    I didn't check 4.1.

Ardb already posted a fix for this [1]

>
> Ok, as I have no idea here, and don't have an arm64 system to do
> anything with (i.e. test), I'll just leave this alone until someone who
> does care about the architecture comes along with a fix :)
>
-- 
Regards,
Sudeep

[1] https://patchwork.kernel.org/patch/8147861/

Re: Build failures in v3.10-stable-queue, v3.14-stable-queue (+4.1, 4.3, 4.4)

[Greg Kroah-Hartman]

On Thu, Jan 28, 2016 at 03:49:46PM +0000, Sudeep Holla wrote:
> 
> 
> On 27/01/16 17:49, Greg Kroah-Hartman wrote:
> >On Wed, Jan 27, 2016 at 09:16:12AM -0800, Guenter Roeck wrote:
> >>On 01/27/2016 08:34 AM, Guenter Roeck wrote:
> >>>On 01/27/2016 04:22 AM, Guenter Roeck wrote:
> >>>[ ... ]
> >>>
> >>>>---
> >>>>mn10300 (v3.10, v3.14):
> >>>>
> >>>>kernel/uid16.c:19:1: error: unknown type name 'old_uid_t'
> >>>>kernel/uid16.c:19:1: error: unknown type name 'old_gid_t'
> >>>>ipc/util.c:609:2: error: 'old_uid_t' undeclared
> >>>>
> >>>>and other similar errors. Requires c86576ea114a ("mn10300: Select CONFIG_HAVE_UID16
> >>>>to fix build failure"). Results in minor easy to resolve conflict in v3.10.y (I didn't
> >>>>check v3.14.y). Let me know if you need a backport.
> >>>>
> >>>4.1 and 4.3 are also affected by this problem.
> >>>
> >>>---
> >>>arm64 (4.1, 4.3):
> >>>
> >>>allmodconfig core dumps (oops). I'll need to look into that one.
> >>>
> >>
> >>Two patches are culprits here:
> >>
> >>- 'recordmcount: arm64: Replace the ignored mcount call into nop' causes the crash.
> >>   It is not the C compiler. Maybe some other patch to recordmcount is missing.
> >>
> 
> This bug is due the endianness mix at-least in my build setup and commit
> c84da8b9ad37 ("recordmcount: Fix endianness handling bug for
> nop_mcount") seems to fix it for me.
> 
> It's already marked for stable and I see that there are quite a few
> patches queued for stable in scripts/recordmcount.[ch]. But I see Greg
> has already pointed this out in the NOTE in his initial "[PATCH 4.1 000/127]
> 4.1.17-stable review" email.
> 
> >>- 'arm64: mm: use correct mapping granularity under DEBUG_RODATA' uses SWAPPER_BLOCK_SIZE
> >>   which is not defined in 4.3. This causes a build failure in 4.3 after reverting the above.
> >>   I didn't check 4.1.
> 
> Ardb already posted a fix for this [1]

Thanks, I should have this all straightened out now...

greg k-h