linux-next: build failure after merge of the origin tree

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi Linus,

Starting with the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_set_interrupt_capability':
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:4724:3: error: implicit declaration of function 'ixgbe_disable_sriov'
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_remove':
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7773:3: error: implicit declaration of function 'ixgbe_check_vf_assignment'

Caused by commit 9487dc844054 ("ixgbe: Fix compiler warnings") which hid
the declarations of ixgbe_disable_sriov() and ixgbe_check_vf_assignment()
when CONFIG_PCI_IOV is not defined.

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 Nov 2011 10:12:02 +1100

> Starting with the origin tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
 ...
> Caused by commit 9487dc844054 ("ixgbe: Fix compiler warnings") which hid
> the declarations of ixgbe_disable_sriov() and ixgbe_check_vf_assignment()
> when CONFIG_PCI_IOV is not defined.
> 
> I have reverted that commit for today.

It should be fixed in net.git, can you please check that the build
succeeds after you pull it into -next?

If you just revert the commit in origin from -next, then you will get
conflicts with you pull the net.git tree in.

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

[Stephen Rothwell]

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

Hi Dave,

On Sun, 06 Nov 2011 20:52:59 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 7 Nov 2011 10:12:02 +1100
> 
> > Starting with the origin tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
>  ...
> > Caused by commit 9487dc844054 ("ixgbe: Fix compiler warnings") which hid
> > the declarations of ixgbe_disable_sriov() and ixgbe_check_vf_assignment()
> > when CONFIG_PCI_IOV is not defined.
> > 
> > I have reverted that commit for today.
> 
> It should be fixed in net.git, can you please check that the build
> succeeds after you pull it into -next?

I reverted the commit above ...

> If you just revert the commit in origin from -next, then you will get
> conflicts with you pull the net.git tree in.

I got no conflicts when I merged in the net tree and can see no fix for
this problem in the net tree.  My current head of the net tree is 1a6422f
"etherh: Add MAINTAINERS entry for etherh".

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 Nov 2011 13:47:06 +1100

>> If you just revert the commit in origin from -next, then you will get
>> conflicts with you pull the net.git tree in.
> 
> I got no conflicts when I merged in the net tree and can see no fix for
> this problem in the net tree.  My current head of the net tree is 1a6422f
> "etherh: Add MAINTAINERS entry for etherh".

Ok, Jeff please take a look at this and send me a fix soon.

Thanks.

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

[Kirsher, Jeffrey T]

Cheers,
Jeff

On Nov 6, 2011, at 19:38, "David Miller" <davem@davemloft.net> wrote:

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 7 Nov 2011 13:47:06 +1100
> 
>>> If you just revert the commit in origin from -next, then you will get
>>> conflicts with you pull the net.git tree in.
>> 
>> I got no conflicts when I merged in the net tree and can see no fix for
>> this problem in the net tree.  My current head of the net tree is 1a6422f
>> "etherh: Add MAINTAINERS entry for etherh".
> 
> Ok, Jeff please take a look at this and send me a fix soon.
> 
> Thanks.

Ok Dave, at this point, I am puttying together a patch to revert this fix since it appears that more trouble comes with this fix.  I will take a look at it quickly before sending out a patch to fix the issue.

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

[Rose, Gregory V]

> -----Original Message-----
> From: Kirsher, Jeffrey T
> Sent: Sunday, November 06, 2011 9:30 PM
> To: David Miller
> Cc: sfr@canb.auug.org.au; torvalds@linux-foundation.org; linux-
> next@vger.kernel.org; linux-kernel@vger.kernel.org; Rose, Gregory V;
> netdev@vger.kernel.org
> Subject: Re: linux-next: build failure after merge of the origin tree
> 
> 
> 
> Cheers,
> Jeff
> 
> On Nov 6, 2011, at 19:38, "David Miller" <davem@davemloft.net> wrote:
> 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 7 Nov 2011 13:47:06 +1100
> >
> >>> If you just revert the commit in origin from -next, then you will get
> >>> conflicts with you pull the net.git tree in.
> >>
> >> I got no conflicts when I merged in the net tree and can see no fix for
> >> this problem in the net tree.  My current head of the net tree is
> 1a6422f
> >> "etherh: Add MAINTAINERS entry for etherh".
> >
> > Ok, Jeff please take a look at this and send me a fix soon.
> >
> > Thanks.
> 
> Ok Dave, at this point, I am puttying together a patch to revert this fix
> since it appears that more trouble comes with this fix.  I will take a
> look at it quickly before sending out a patch to fix the issue.

My bad...  I fixed a compiler warning that occurred with CONFIG_PCI_IOV turned on and didn't realize that my patch would cause an error when turning it back off.

I'll have it fixed ASAP.

- Greg

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

[Rose, Gregory V]

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

> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Rose, Gregory V
> Sent: Monday, November 07, 2011 8:47 AM
> To: Kirsher, Jeffrey T; David Miller
> Cc: sfr@canb.auug.org.au; torvalds@linux-foundation.org; linux-
> next@vger.kernel.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: RE: linux-next: build failure after merge of the origin tree
> 
> 
> 
> > -----Original Message-----
> > From: Kirsher, Jeffrey T
> > Sent: Sunday, November 06, 2011 9:30 PM
> > To: David Miller
> > Cc: sfr@canb.auug.org.au; torvalds@linux-foundation.org; linux-
> > next@vger.kernel.org; linux-kernel@vger.kernel.org; Rose, Gregory V;
> > netdev@vger.kernel.org
> > Subject: Re: linux-next: build failure after merge of the origin tree
> >
> >
> >
> > Cheers,
> > Jeff
> >
> > On Nov 6, 2011, at 19:38, "David Miller" <davem@davemloft.net> wrote:
> >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Mon, 7 Nov 2011 13:47:06 +1100
> > >
> > >>> If you just revert the commit in origin from -next, then you will
> get
> > >>> conflicts with you pull the net.git tree in.
> > >>
> > >> I got no conflicts when I merged in the net tree and can see no fix
> for
> > >> this problem in the net tree.  My current head of the net tree is
> > 1a6422f
> > >> "etherh: Add MAINTAINERS entry for etherh".
> > >
> > > Ok, Jeff please take a look at this and send me a fix soon.
> > >
> > > Thanks.
> >
> > Ok Dave, at this point, I am puttying together a patch to revert this
> fix
> > since it appears that more trouble comes with this fix.  I will take a
> > look at it quickly before sending out a patch to fix the issue.
> 
> My bad...  I fixed a compiler warning that occurred with CONFIG_PCI_IOV
> turned on and didn't realize that my patch would cause an error when
> turning it back off.
> 
> I'll have it fixed ASAP.
> 
> - Greg

I have posted a fix for this problem to netdev and attached it to this email.

Again, my apologies for the mix up.

- Greg


> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Type: message/rfc822, Size: 5342 bytes --]

From: "Rose, Gregory V" <gregory.v.rose@intel.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>
Subject: [net-ext PATCH] ixgbe: Fix compile for kernel without CONFIG_PCI_IOV	defined
Date: Mon, 7 Nov 2011 09:44:17 -0800
Message-ID: <20111107174417.8638.87569.stgit@gitlad.jf.intel.com>

Fix compiler errors and warnings with CONFIG_PCI_IOV defined and not
defined.

Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
---

 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c |    2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h |    4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index db95731..00fcd39 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -442,12 +442,14 @@ static int ixgbe_set_vf_macvlan(struct ixgbe_adapter *adapter,

 int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter)
 {
+#ifdef CONFIG_PCI_IOV
        int i;
        for (i = 0; i < adapter->num_vfs; i++) {
                if (adapter->vfinfo[i].vfdev->dev_flags &
                                PCI_DEV_FLAGS_ASSIGNED)
                        return true;
        }
+#endif
        return false;
 }

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
index 4a5d889..df04f1a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
@@ -42,11 +42,11 @@ int ixgbe_ndo_set_vf_spoofchk(struct net_device *netdev, int vf, bool setting);
 int ixgbe_ndo_get_vf_config(struct net_device *netdev,
                            int vf, struct ifla_vf_info *ivi);
 void ixgbe_check_vf_rate_limit(struct ixgbe_adapter *adapter);
-#ifdef CONFIG_PCI_IOV
 void ixgbe_disable_sriov(struct ixgbe_adapter *adapter);
+int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter);
+#ifdef CONFIG_PCI_IOV
 void ixgbe_enable_sriov(struct ixgbe_adapter *adapter,
                        const struct ixgbe_info *ii);
-int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter);
 #endif



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

After merging the origin tree, today's linux-next build (sparc defconfig)
failed like this:

<stdin>:1519:2: warning: #warning syscall clone3 not implemented [-Wcpp]
/home/sfr/next/next/arch/sparc/mm/fault_32.c: In function 'force_user_fault':
/home/sfr/next/next/arch/sparc/mm/fault_32.c:315:49: error: 'regs' undeclared (first use in this function)
  315 |         vma = lock_mm_and_find_vma(mm, address, regs);
      |                                                 ^~~~

Caused by commit

  a050ba1e7422 ("mm/fault: convert remaining simple cases to lock_mm_and_find_vma()")

I have just left this broken for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Linus Torvalds]

On Thu, 29 Jun 2023 at 19:59, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the origin tree, today's linux-next build (sparc defconfig)
> failed like this:
>
> /home/sfr/next/next/arch/sparc/mm/fault_32.c: In function 'force_user_fault':
> /home/sfr/next/next/arch/sparc/mm/fault_32.c:315:49: error: 'regs' undeclared (first use in this function)
>   315 |         vma = lock_mm_and_find_vma(mm, address, regs);

Duh. Yeah, the register window faults don't pass the user register
state pointer around, and as noted in commit a050ba1e7422 those
left-over conversions were mostly done blind.

The fix is trivial - just pass in NULL for the regs pointer. It's not required.

Said fix pushed out. Thanks,

               Linus

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

Building Linus' tree, today's linux-next build (sparc64 allmodconfig,
arm64 allmodconfig, riscv defconfig and others) failed like this:

In file included from arch/sparc/include/asm/io_32.h:21:0,
                 from arch/sparc/include/asm/io.h:7,
                 from arch/sparc/vdso/vdso32/../vclock_gettime.c:18,
                 from arch/sparc/vdso/vdso32/vclock_gettime.c:22:
include/asm-generic/io.h:1059:21: error: static declaration of 'pci_iounmap' follows non-static declaration
 #define pci_iounmap pci_iounmap
                     ^
include/asm-generic/io.h:1060:20: note: in expansion of macro 'pci_iounmap'
 static inline void pci_iounmap(struct pci_dev *dev, void __iomem *p)
                    ^

Presumably caused by commit

  9caea0007601 ("parisc: Declare pci_iounmap() parisc version only when CONFIG_PCI enabled")

-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

After merging the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from <command-line>:
include/linux/compiler_attributes.h:62:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
   62 | #if __has_attribute(__assume_aligned__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:62:20: error: missing binary operator before token "("
   62 | #if __has_attribute(__assume_aligned__)
      |                    ^
include/linux/compiler_attributes.h:88:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
   88 | #if __has_attribute(__copy__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:88:20: error: missing binary operator before token "("
   88 | #if __has_attribute(__copy__)
      |                    ^
include/linux/compiler_attributes.h:113:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  113 | #if __has_attribute(__designated_init__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:113:20: error: missing binary operator before token "("
  113 | #if __has_attribute(__designated_init__)
      |                    ^
include/linux/compiler_attributes.h:124:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  124 | #if __has_attribute(__error__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:124:20: error: missing binary operator before token "("
  124 | #if __has_attribute(__error__)
      |                    ^
include/linux/compiler_attributes.h:135:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  135 | #if __has_attribute(__externally_visible__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:135:20: error: missing binary operator before token "("
  135 | #if __has_attribute(__externally_visible__)
      |                    ^
In file included from <command-line>:
include/linux/compiler_attributes.h:171:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  171 | #if __has_attribute(__no_caller_saved_registers__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:171:20: error: missing binary operator before token "("
  171 | #if __has_attribute(__no_caller_saved_registers__)
      |                    ^
include/linux/compiler_attributes.h:182:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  182 | #if __has_attribute(__noclone__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:182:20: error: missing binary operator before token "("
  182 | #if __has_attribute(__noclone__)
      |                    ^
include/linux/compiler_attributes.h:199:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  199 | #if __has_attribute(__fallthrough__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:199:20: error: missing binary operator before token "("
  199 | #if __has_attribute(__fallthrough__)
      |                    ^
include/linux/compiler_attributes.h:226:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  226 | #if __has_attribute(__nonstring__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:226:20: error: missing binary operator before token "("
  226 | #if __has_attribute(__nonstring__)
      |                    ^
include/linux/compiler_attributes.h:238:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  238 | #if __has_attribute(__no_profile_instrument_function__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:238:20: error: missing binary operator before token "("
  238 | #if __has_attribute(__no_profile_instrument_function__)
      |                    ^
include/linux/compiler_attributes.h:296:5: warning: "__has_attribute" is not defined, evaluates to 0 [-Wundef]
  296 | #if __has_attribute(__warning__)
      |     ^~~~~~~~~~~~~~~
include/linux/compiler_attributes.h:296:20: error: missing binary operator before token "("
  296 | #if __has_attribute(__warning__)
      |                    ^
make[2]: *** [arch/powerpc/boot/Makefile:225: arch/powerpc/boot/crt0.o] Error 1

Exposed by commit

  6d2ef226f2f1 ("compiler_attributes.h: drop __has_attribute() support for gcc4")

Powerpc uses BOOTAS to build arch/powerpc/boot/crt0.o (and others)
which (with V=1) is

  gcc -Wp,-MD,arch/powerpc/boot/.crt0.o.d -D__ASSEMBLY__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc -include /home/sfr/next/next/include/linux/compiler_attributes.h -I/home/sfr/next/next/arch/powerpc/include -I./arch/powerpc/include/generated -I/home/sfr/next/next/include -I./include -I/home/sfr/next/next/arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I/home/sfr/next/next/include/uapi -I./include/generated/uapi -include /home/sfr/next/next/include/linux/compiler-version.h -include /home/sfr/next/next/include/linux/kconfig.h -m32 -isystem /usr/lib/gcc/powerpc64le-linux-gnu/10/include -mbig-endian -nostdinc -c -o arch/powerpc/boot/crt0.o /home/sfr/next/next/arch/powerpc/boot/crt0.S

I am not sure what is missing here to get __has_attribute defined.

I have reverted the above commit for today ( and reapplied the bits
from commits

  7ed012969bbc ("Compiler Attributes: fix __has_attribute(__no_sanitize_coverage__) for GCC 4")
  b83a908498d6 ("compiler_attributes.h: move __compiletime_{error|warning}")
).

I assume that this needs some work in the powerpc arch Makfile(s) ...
-- 
Cheers,
Stephen Rothwell

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

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

[Linus Torvalds]

On Mon, Sep 13, 2021 at 5:09 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>   gcc -Wp,-MD,arch/powerpc/boot/.crt0.o.d

Ok, so it's not the funky "clang reports gcc-4" that caused tool breakage.

What version of gcc is this? Are you maybe on gcc-4.9 and we just
didn't check that properly?

              Linus

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

[Linus Torvalds]

On Mon, Sep 13, 2021 at 5:19 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> What version of gcc is this? Are you maybe on gcc-4.9 and we just
> didn't check that properly?

Hmm. That version check works for me (tested by just arbitrarily
making min-tool-version return version 15 for gcc ;)

So you got far enough that I don't believe you have gcc-4.

I have no idea why it then complains about removal of the GCC4 macros.

Can somebody hit me with the clue-bat?

            Linus

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

[Stephen Rothwell]

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

Hi Linus,

On Mon, 13 Sep 2021 17:24:11 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Mon, Sep 13, 2021 at 5:19 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > What version of gcc is this? Are you maybe on gcc-4.9 and we just
> > didn't check that properly?  
> 
> Hmm. That version check works for me (tested by just arbitrarily
> making min-tool-version return version 15 for gcc ;)
> 
> So you got far enough that I don't believe you have gcc-4.

$ gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 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.

> I have no idea why it then complains about removal of the GCC4 macros.

Me neither :-(

-- 
Cheers,
Stephen Rothwell

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

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

[Linus Torvalds]

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

On Mon, Sep 13, 2021 at 5:58 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > I have no idea why it then complains about removal of the GCC4 macros.
>
> Me neither :-(

Ooh.

So I'm looking at gcc sources, just to see if "maybe this thing is
somehow conditional".

And bingo.

In cpp_init_special_builtins(), gcc does

      if (b->value == BT_HAS_ATTRIBUTE
          && (CPP_OPTION (pfile, lang) == CLK_ASM
              || pfile->cb.has_attribute == NULL))
        continue;

which basically says that if we're pre-processing an ASM file, the
magical pre-processor symbol for __has_attribute is not defined.

I'm not sure what that 'pfile->cb.has_attribute == NULL' thing means,
but the libcpp/ChangeLog file also mentions this:

        (cpp_init_special_builtins): Don't initialize __has_attribute
        or __has_cpp_attribute if CLK_ASM or pfile->cb.has_attribute is NULL.

So this is a very very special magical thing: if building an *.S file,
__has_attribute magically goes away.

And sure enough, that's exactly what is going on. It's during that
build of arch/powerpc/boot/crt0.S, and the reason this hits on powerpc
is that in arch/powerpc/boot/Makefile we have

         -include $(srctree)/include/linux/compiler_attributes.h

as part of BOOTCFLAGS, and then it does

        BOOTAFLAGS      := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc

to also include that header file when building ASM files.

And our old GCC4 code silently hid this all, and made it work, because
for a *.S file  you'd then (completely illogically) get those fake
gcc-4 attribute macros.

Now, do I know *why* that ppc Makefile it does that? No. Neither do I
know why the gcc people decided to just make ASM preprocessor so
special.

But at least I understand how the odd error happens.

This was too damn subtle. When you have to go read the compiler
sources to figure things like this out, you know you are too deep.

The fix should be pretty simple: remove almost all of BOOTCFLAGS from
BOOTAFLAGS.

But sadly, "almost all" isn't "all". There's the include path stuff,
there's the ABI and endianness, and there's the bit size ones.

So I think the fix is either

 (a) remove that

         -include $(srctree)/include/linux/compiler_attributes.h

     thing entirely, and add it as required to the C files.

OR

 (b) something like this ENTIRELY UNTESTED ATTACHED patch

I will leave it to the powerpc people to make the right choice.

               Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1611 bytes --]

 arch/powerpc/boot/Makefile | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 6900d0ac2421..9bcf62d65509 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -32,28 +32,30 @@ else
     BOOTAR := $(AR)
 endif
 
-BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-		 -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \
-		 -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-		 -include $(srctree)/include/linux/compiler_attributes.h \
-		 $(LINUXINCLUDE)
+BOOTCOREFLAGS := $(LINUXINCLUDE)
 
 ifdef CONFIG_PPC64_BOOT_WRAPPER
-BOOTCFLAGS	+= -m64
+BOOTCOREFLAGS	+= -m64
 else
-BOOTCFLAGS	+= -m32
+BOOTCOREFLAGS	+= -m32
 endif
 
-BOOTCFLAGS	+= -isystem $(shell $(BOOTCC) -print-file-name=include)
+BOOTCOREFLAGS	+= -isystem $(shell $(BOOTCC) -print-file-name=include)
 
 ifdef CONFIG_CPU_BIG_ENDIAN
-BOOTCFLAGS	+= -mbig-endian
+BOOTCOREFLAGS	+= -mbig-endian
 else
-BOOTCFLAGS	+= -mlittle-endian
-BOOTCFLAGS	+= $(call cc-option,-mabi=elfv2)
+BOOTCOREFLAGS	+= -mlittle-endian
+BOOTCOREFLAGS	+= $(call cc-option,-mabi=elfv2)
 endif
 
-BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
+BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
+		 -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \
+		 -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
+		 -include $(srctree)/include/linux/compiler_attributes.h \
+		 $(BOOTCOREFLAGS)
+
+BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCOREFLAGS) -nostdinc
 
 BOOTARFLAGS	:= -crD
 

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

[Linus Torvalds]

On Mon, Sep 13, 2021 at 6:29 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Now, do I know *why* that ppc Makefile it does that? No.

Well, that is simple enough to find out..

        git show 77433830ed164

just tells us.

Of course, that also points to scripts/Makefile.lib, which doesn't
have this problem, because it keeps c_flags and a_flags nicely
separated.

Anyway, that just makes me think that something like that patch in my
previous email is the way to go, but I would like to stress (again)
how little testing it had: exactly none.

So please consider that nothing more than a hand-wavy "something like this".

              Linus

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

[Linus Torvalds]

On Mon, Sep 13, 2021 at 6:37 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Anyway, that just makes me think that something like that patch in my
> previous email is the way to go, but I would like to stress (again)
> how little testing it had: exactly none.
>
> So please consider that nothing more than a hand-wavy "something like this".

The alternative would be to just add a

  #ifndef __ASSEMBLY__
  ...
  #endif

around the whole thing. I could do that without asking for help from
the powerpc people.

But it really does seem kind of wrong to include a "compiler
attributes" header file to compile a *.S file. It's not like any of
those attributes are valid in asm anyway.

I did just verify that the patch I sent out seems to cross-compile ok.
At least for the power64 defconfig.

So that's _some_ testing, and implies that the patch isn't complete garbage.

          Linus

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

[Stephen Rothwell]

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

Hi Linus,

On Mon, 13 Sep 2021 18:29:26 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Mon, Sep 13, 2021 at 5:58 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > I have no idea why it then complains about removal of the GCC4 macros.
> >
> > Me neither :-(
> 
> Ooh.
> 
> So I'm looking at gcc sources, just to see if "maybe this thing is
> somehow conditional".
> 
> And bingo.
> 
> In cpp_init_special_builtins(), gcc does
> 
>       if (b->value == BT_HAS_ATTRIBUTE
>           && (CPP_OPTION (pfile, lang) == CLK_ASM
>               || pfile->cb.has_attribute == NULL))
>         continue;
> 
> which basically says that if we're pre-processing an ASM file, the
> magical pre-processor symbol for __has_attribute is not defined.
> 
> I'm not sure what that 'pfile->cb.has_attribute == NULL' thing means,
> but the libcpp/ChangeLog file also mentions this:
> 
>         (cpp_init_special_builtins): Don't initialize __has_attribute
>         or __has_cpp_attribute if CLK_ASM or pfile->cb.has_attribute is NULL.
> 
> So this is a very very special magical thing: if building an *.S file,
> __has_attribute magically goes away.
> 
> And sure enough, that's exactly what is going on. It's during that
> build of arch/powerpc/boot/crt0.S, and the reason this hits on powerpc
> is that in arch/powerpc/boot/Makefile we have
> 
>          -include $(srctree)/include/linux/compiler_attributes.h
> 
> as part of BOOTCFLAGS, and then it does
> 
>         BOOTAFLAGS      := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
> 
> to also include that header file when building ASM files.
> 
> And our old GCC4 code silently hid this all, and made it work, because
> for a *.S file  you'd then (completely illogically) get those fake
> gcc-4 attribute macros.
> 
> Now, do I know *why* that ppc Makefile it does that? No. Neither do I
> know why the gcc people decided to just make ASM preprocessor so
> special.
> 
> But at least I understand how the odd error happens.

Its good to know there is a reason :-)

> This was too damn subtle. When you have to go read the compiler
> sources to figure things like this out, you know you are too deep.
> 
> The fix should be pretty simple: remove almost all of BOOTCFLAGS from
> BOOTAFLAGS.
> 
> But sadly, "almost all" isn't "all". There's the include path stuff,
> there's the ABI and endianness, and there's the bit size ones.
> 
> So I think the fix is either
> 
>  (a) remove that
> 
>          -include $(srctree)/include/linux/compiler_attributes.h
> 
>      thing entirely, and add it as required to the C files.
> 
> OR
> 
>  (b) something like this ENTIRELY UNTESTED ATTACHED patch
> 
> I will leave it to the powerpc people to make the right choice.

That patch works for me - for the ppc64_defconfig build at least.

-- 
Cheers,
Stephen Rothwell

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

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

[Linus Torvalds]

On Mon, Sep 13, 2021 at 7:08 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> That patch works for me - for the ppc64_defconfig build at least.

Yeah, I just tested the allmodconfig case too, although I suspect it's
essentially the same wrt the boot *.S files, so it probably doesn't
matter.

I'd like to have Michael or somebody who can actually run some tests
on the end result ack that patch (or - even better - come up with
something cleaner) before committing it.

Because yeah, the build failure is annoying and I apologize, but I'd
rather have the build fail overnight than commit something that builds
but then is subtle buggy for some reason.

But if I don't get any other comments by the time I'm up again
tomorrow, I'll just commit it as "fixes the build".

                  Linus

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

[Michael Ellerman]

Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Sep 13, 2021 at 7:08 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> That patch works for me - for the ppc64_defconfig build at least.
>
> Yeah, I just tested the allmodconfig case too, although I suspect it's
> essentially the same wrt the boot *.S files, so it probably doesn't
> matter.
>
> I'd like to have Michael or somebody who can actually run some tests
> on the end result ack that patch (or - even better - come up with
> something cleaner) before committing it.
>
> Because yeah, the build failure is annoying and I apologize, but I'd
> rather have the build fail overnight than commit something that builds
> but then is subtle buggy for some reason.
>
> But if I don't get any other comments by the time I'm up again
> tomorrow, I'll just commit it as "fixes the build".

I'll have a look and get back to you before tomorrow.

cheers

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

[Michael Ellerman]

Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Sep 13, 2021 at 7:08 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> That patch works for me - for the ppc64_defconfig build at least.
>
> Yeah, I just tested the allmodconfig case too, although I suspect it's
> essentially the same wrt the boot *.S files, so it probably doesn't
> matter.
>
> I'd like to have Michael or somebody who can actually run some tests
> on the end result ack that patch (or - even better - come up with
> something cleaner) before committing it.
>
> Because yeah, the build failure is annoying and I apologize, but I'd
> rather have the build fail overnight than commit something that builds
> but then is subtle buggy for some reason.
>
> But if I don't get any other comments by the time I'm up again
> tomorrow, I'll just commit it as "fixes the build".

I ended up doing a more minimal version of your change.

I sent it separately, or it's here:

  https://lore.kernel.org/lkml/20210914121723.3756817-1-mpe@ellerman.id.au/


cheers

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

[Stephen Rothwell]

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

Hi all,

On Tue, 14 Sep 2021 12:08:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> That patch works for me - for the ppc64_defconfig build at least.

also allnoconfig, 64bit allnoconfig, pseries_le_defconfig and ppc44x_defconfig
-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

Building Linus' tree, today's linux-next build (mips
allmodconfig) failed like this:

In file included from /kisskb/src/include/linux/compiler_types.h:65:0,
                 from <command-line>:0:
include/linux/compiler_attributes.h:29:29: error: "__GCC4_has_attribute___no_sanitize_coverage__" is not defined [-Werror=undef]
 # define __has_attribute(x) __GCC4_has_attribute_##x
                             ^
include/linux/compiler-gcc.h:125:29: note: in expansion of macro '__has_attribute'
 #if defined(CONFIG_KCOV) && __has_attribute(__no_sanitize_coverage__)
                             ^
cc1: all warnings being treated as errors

Caused by commit

  540540d06e9d ("kcov: add __no_sanitize_coverage to fix noinstr for all architectures")

This ia a gcc 4.9 build, so presumably this?

diff -ru a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
--- a/include/linux/compiler_attributes.h	2021-09-08 09:03:35.169225661 +1000
+++ b/include/linux/compiler_attributes.h	2021-09-08 09:05:47.790907780 +1000
@@ -36,6 +36,7 @@
 # define __GCC4_has_attribute___no_profile_instrument_function__ 0
 # define __GCC4_has_attribute___nonstring__           0
 # define __GCC4_has_attribute___no_sanitize_address__ 1
+# define __GCC4_has_attribute___no_sanitize_coverage__	0
 # define __GCC4_has_attribute___no_sanitize_undefined__ 1
 # define __GCC4_has_attribute___fallthrough__         0
 #endif

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Wed, 8 Sep 2021 09:07:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Building Linus' tree, today's linux-next build (mips
> allmodconfig) failed like this:
> 
> In file included from /kisskb/src/include/linux/compiler_types.h:65:0,
>                  from <command-line>:0:
> include/linux/compiler_attributes.h:29:29: error: "__GCC4_has_attribute___no_sanitize_coverage__" is not defined [-Werror=undef]
>  # define __has_attribute(x) __GCC4_has_attribute_##x
>                              ^
> include/linux/compiler-gcc.h:125:29: note: in expansion of macro '__has_attribute'
>  #if defined(CONFIG_KCOV) && __has_attribute(__no_sanitize_coverage__)
>                              ^
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   540540d06e9d ("kcov: add __no_sanitize_coverage to fix noinstr for all architectures")
> 
> This ia a gcc 4.9 build, so presumably this?
> 
> diff -ru a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> --- a/include/linux/compiler_attributes.h	2021-09-08 09:03:35.169225661 +1000
> +++ b/include/linux/compiler_attributes.h	2021-09-08 09:05:47.790907780 +1000
> @@ -36,6 +36,7 @@
>  # define __GCC4_has_attribute___no_profile_instrument_function__ 0
>  # define __GCC4_has_attribute___nonstring__           0
>  # define __GCC4_has_attribute___no_sanitize_address__ 1
> +# define __GCC4_has_attribute___no_sanitize_coverage__	0
>  # define __GCC4_has_attribute___no_sanitize_undefined__ 1
>  # define __GCC4_has_attribute___fallthrough__         0
>  #endif

Just to be clear, I haven't tested the above in any way.

-- 
Cheers,
Stephen Rothwell

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

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

[Marco Elver]

On Wed, 8 Sept 2021 at 01:09, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Wed, 8 Sep 2021 09:07:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Building Linus' tree, today's linux-next build (mips
> > allmodconfig) failed like this:
> >
> > In file included from /kisskb/src/include/linux/compiler_types.h:65:0,
> >                  from <command-line>:0:
> > include/linux/compiler_attributes.h:29:29: error: "__GCC4_has_attribute___no_sanitize_coverage__" is not defined [-Werror=undef]
> >  # define __has_attribute(x) __GCC4_has_attribute_##x
> >                              ^
> > include/linux/compiler-gcc.h:125:29: note: in expansion of macro '__has_attribute'
> >  #if defined(CONFIG_KCOV) && __has_attribute(__no_sanitize_coverage__)
> >                              ^
> > cc1: all warnings being treated as errors
> >
> > Caused by commit
> >
> >   540540d06e9d ("kcov: add __no_sanitize_coverage to fix noinstr for all architectures")
> >
> > This ia a gcc 4.9 build, so presumably this?
> >
> > diff -ru a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> > --- a/include/linux/compiler_attributes.h     2021-09-08 09:03:35.169225661 +1000
> > +++ b/include/linux/compiler_attributes.h     2021-09-08 09:05:47.790907780 +1000
> > @@ -36,6 +36,7 @@
> >  # define __GCC4_has_attribute___no_profile_instrument_function__ 0
> >  # define __GCC4_has_attribute___nonstring__           0
> >  # define __GCC4_has_attribute___no_sanitize_address__ 1
> > +# define __GCC4_has_attribute___no_sanitize_coverage__       0
> >  # define __GCC4_has_attribute___no_sanitize_undefined__ 1
> >  # define __GCC4_has_attribute___fallthrough__         0
> >  #endif
>
> Just to be clear, I haven't tested the above in any way.

I see this in next-20210907: "Compiler Attributes: fix
__has_attribute(__no_sanitize_coverage__) for GCC 4"
Which does the same fix.

Not sure what happened to it.

I would have also expected this to be merged as a fix into mainline by
now? Miguel?

Thanks,
-- Marco

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

[Miguel Ojeda]

On Wed, Sep 8, 2021 at 1:17 AM Marco Elver <elver@google.com> wrote:
>
> I see this in next-20210907: "Compiler Attributes: fix
> __has_attribute(__no_sanitize_coverage__) for GCC 4"
> Which does the same fix.
>
> Not sure what happened to it.
>
> I would have also expected this to be merged as a fix into mainline by
> now? Miguel?

Yes, sorry, I have some things in my queues -- I will send them in a few hours.

Cheers,
Miguel

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

After merging the origin tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/linux/random.h:14,
                 from arch/arm/kernel/signal.c:8:
arch/arm/include/asm/percpu.h: In function '__my_cpu_offset':
arch/arm/include/asm/percpu.h:29:34: error: 'current_stack_pointer' undeclared (first use in this function); did you mean 'user_stack_pointer'?
   29 |   : "Q" (*(const unsigned long *)current_stack_pointer));
      |                                  ^~~~~~~~~~~~~~~~~~~~~
      |                                  user_stack_pointer

Presumably aused by commit

  1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")

I have added this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 31 Jul 2020 08:50:31 +1000
Subject: [PATCH] arm: include asm/thread_info.h in asm/percpu.h

This need was uncovered by commit

  1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/include/asm/percpu.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
index f44f448537f2..ebfa06bebea5 100644
--- a/arch/arm/include/asm/percpu.h
+++ b/arch/arm/include/asm/percpu.h
@@ -10,6 +10,9 @@
  * in the TPIDRPRW. TPIDRPRW only exists on V6K and V7
  */
 #if defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
+
+#include <asm/thread_info.h>	/* for current_stack_pointer */
+
 static inline void set_my_cpu_offset(unsigned long off)
 {
 	/* Set TPIDRPRW */
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Fri, 31 Jul 2020 08:58:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the origin tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from include/linux/random.h:14,
>                  from arch/arm/kernel/signal.c:8:
> arch/arm/include/asm/percpu.h: In function '__my_cpu_offset':
> arch/arm/include/asm/percpu.h:29:34: error: 'current_stack_pointer' undeclared (first use in this function); did you mean 'user_stack_pointer'?
>    29 |   : "Q" (*(const unsigned long *)current_stack_pointer));
>       |                                  ^~~~~~~~~~~~~~~~~~~~~
>       |                                  user_stack_pointer
> 
> Presumably aused by commit
> 
>   1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
> 
> I have added this fix patch for today:

Looks like I sould read further ahead in my email :-)

-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

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

In file included from include/asm-generic/percpu.h:7,
                 from arch/x86/include/asm/percpu.h:556,
                 from arch/x86/include/asm/preempt.h:6,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:51,
                 from include/linux/seqlock.h:36,
                 from include/linux/time.h:6,
                 from include/linux/stat.h:19,
                 from include/linux/module.h:13,
                 from arch/x86/crypto/glue_helper.c:13:
include/linux/random.h:123:24: error: variable 'net_rand_state' with 'latent_entropy' attribute must not be local
  123 | DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
      |                        ^~~~~~~~~
include/linux/percpu-defs.h:88:38: note: in definition of macro 'DECLARE_PER_CPU_SECTION'
   88 |  extern __PCPU_ATTRS(sec) __typeof__(type) name
      |                                      ^~~~
include/linux/random.h:123:1: note: in expansion of macro 'DECLARE_PER_CPU'
  123 | DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
      | ^~~~~~~~~~~~~~~

Caused by commit

  f227e3ec3b5c ("random32: update the net random state on interrupt and activity")

I have reverted that commit for today.

In case it matters:

$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 9.3.0-13) 9.3.0

-- 
Cheers,
Stephen Rothwell

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

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

[Linus Torvalds]

On Wed, Jul 29, 2020 at 4:08 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> include/linux/random.h:123:24: error: variable 'net_rand_state' with 'latent_entropy' attribute must not be local
>   123 | DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;

Hmm.

Ok, this shows a limitation of my allmodconfig testing (and all my
normal builds) - no plugins. So that problem wasn't as obvious as it
should have been.

That error isn't very helpful, in that I think it actually is very
wrong. The variable really isn't local at all.

I think what the plugin *means* by "local" is "automatic", and I think
it uses the wrong test for it. IOW, looking at the plugin, it does

                if (!TREE_STATIC(*node)) {
                        *no_add_attrs = true;
                        error("variable %qD with %qE attribute must
not be local",
                                *node, name);

and what I think it really wants is that it has a static address - so
a global variable is fine - as opposed to being an actual static
declaration.

Also looking at the plugin, I suspect it is going to be very unhappy
about the fact that the attribute is there both on a declaration and
on the actual definition. The code later seems to really only want to
work on the definition, since it's creating an initializer..

IOW, I get the feeling that the plugin is confused, and it so happened
that the only variables we'd marked for latent entropy were static
ones. But I haven't done gcc plugins, so...

Adding the gcc plugin people. Otherwise the only option seems to be to
just remove that __latent_entropy marker.

                    Linus

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

[Linus Torvalds]

On Wed, Jul 29, 2020 at 4:43 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Ok, this shows a limitation of my allmodconfig testing (and all my
> normal builds) - no plugins. So that problem wasn't as obvious as it
> should have been.

Ok, that was easy to install and get the coverage, and now I see the error.

Except I still don't know the gcc plugins well enough to fix it at the
plugin level. And the gcc docs only talk about TREE_STATIC() for
functions, not for variables. Apparently variables should use
DECL_THIS_EXTERN or DECL_THIS_STATIC according to the docs I find, but
..

Removing the __latent_entropy marker obviously fixes things.

               Linus

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

[Linus Torvalds]

On Wed, Jul 29, 2020 at 5:09 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Removing the __latent_entropy marker obviously fixes things.

Ok, I did that for now. I spent a few minutes looking at the gcc
plugin in case I'd be hit by some sudden stroke of genius, but that
didn't happen, so let's avoid the issue until somebody who knows the
gcc plugins better can come up with what the right solution is.

            Linus

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

[Willy Tarreau]

On Wed, Jul 29, 2020 at 07:12:58PM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 5:09 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Removing the __latent_entropy marker obviously fixes things.
> 
> Ok, I did that for now. I spent a few minutes looking at the gcc
> plugin in case I'd be hit by some sudden stroke of genius, but that
> didn't happen, so let's avoid the issue until somebody who knows the
> gcc plugins better can come up with what the right solution is.

I've looked if we couldn't we work around this by declaring another
static variable with __latent_entropy and use it to initialize
net_rand_state early, for example in prandom_init(), but there we
already fill net_rand_state with randoms so I'm wondering if that
__latent_entropy is used before prandom_init() or if its sole purpose
is to provide extra initial entropy to be combined with the one
prandom_init() will add.

Willy

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

[Kees Cook]

On Wed, Jul 29, 2020 at 04:43:04PM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 4:08 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > include/linux/random.h:123:24: error: variable 'net_rand_state' with 'latent_entropy' attribute must not be local
> >   123 | DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
> 
> Hmm.
> 
> Ok, this shows a limitation of my allmodconfig testing (and all my
> normal builds) - no plugins. So that problem wasn't as obvious as it
> should have been.

I'll look into this more tomorrow. (But yes, __latent_entropy is
absolutely used for globals already, as you found, but this is the first
percpu it was applied to...)

> Adding the gcc plugin people. Otherwise the only option seems to be to
> just remove that __latent_entropy marker.

And just another heads-up, the patch[1] (which was never sent to a public
list) also breaks arm64 (circular header needs?):

$ make CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 defconfig
...
$ make -j$(getconf _NPROCESSORS_ONLN) CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64
...
In file included from ./arch/arm64/include/asm/smp.h:33,
                 from ./include/linux/smp.h:82,
                 from ./include/linux/percpu.h:7,
                 from ./include/linux/random.h:14,
                 from arch/arm64/kernel/pointer_auth.c:5:
./arch/arm64/include/asm/pointer_auth.h: In function ‘ptrauth_keys_init_user’:
./arch/arm64/include/asm/pointer_auth.h:40:3: error: implicit declaration of function ‘get_random_bytes’; did you mean ‘get_random_once’? [-Werror=implicit-function-declaration]
   40 |   get_random_bytes(&keys->apia, sizeof(keys->apia));
      |   ^~~~~


[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f227e3ec3b5cad859ad15666874405e8c1bbc1d4

-- 
Kees Cook

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

[Willy Tarreau]

Hi Kees,

On Wed, Jul 29, 2020 at 08:17:48PM -0700, Kees Cook wrote:
> And just another heads-up, the patch[1] (which was never sent to a public
> list) also breaks arm64 (circular header needs?):
(...)

Definitely, we've just got a report about this, I'll have a look once
I'm at the office. I'd like to check that we don't obviously break
another arch by just removing percpu. If at least shuffling them around
is sufficient that'd be nice. Otherwise we'll likely need a separate
header (which is not a bad thing for the long term).

Thanks!
Willy

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

[Willy Tarreau]

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

On Thu, Jul 30, 2020 at 05:22:50AM +0200, Willy Tarreau wrote:
> On Wed, Jul 29, 2020 at 08:17:48PM -0700, Kees Cook wrote:
> > And just another heads-up, the patch[1] (which was never sent to a public
> > list) also breaks arm64 (circular header needs?):
> (...)
> 
> Definitely, we've just got a report about this, I'll have a look once
> I'm at the office. I'd like to check that we don't obviously break
> another arch by just removing percpu. If at least shuffling them around
> is sufficient that'd be nice. Otherwise we'll likely need a separate
> header (which is not a bad thing for the long term).

So Linus proposed a clean solution which might be harder to backport
but looks better for 5.8. However the attached one addresses the issue
for me on arm64 and still works on x86_64, arm, mips. I think we should
go with this one first then apply Linus' one on top of it to be long
term proof, and backport only the first one. Linus ?

Willy

[-- Attachment #2: 0001-random-fix-circular-include-dependency-on-arm64-afte.patch --]
[-- Type: text/plain, Size: 1694 bytes --]

From 18fba9e2dfb16605a722e01f95d9e2d020efaa42 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Thu, 30 Jul 2020 07:59:24 +0200
Subject: random: fix circular include dependency on arm64 after addition of
 percpu.h
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit

Daniel Díaz and Kees Cook independently reported that commit f227e3ec3b5c
("random32: update the net random state on interrupt and activity") broke
arm64 due to a circular dependency on include files since the addition of
percpu.h in random.h.

The correct fix would definitely be to move all the prandom32 stuff out
of random.h but for backporting, a smaller solution is preferred. This
one replaces linux/percpu.h with asm/percpu.h, and this fixes the problem
on x86_64, arm64, arm, and mips. Note that moving percpu.h around didn't
change anything and that removing it entirely broke differently. When
backporting, such options might still be considered if this patch fails
to help.

Reported-by: Daniel Díaz <daniel.diaz@linaro.org>
Reported-by: Kees Cook <keescook@chromium.org>
Fixes: f227e3ec3b5c
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 include/linux/random.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/random.h b/include/linux/random.h
index f310897f051d..9ab7443bd91b 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -11,7 +11,7 @@
 #include <linux/kernel.h>
 #include <linux/list.h>
 #include <linux/once.h>
-#include <linux/percpu.h>
+#include <asm/percpu.h>
 
 #include <uapi/linux/random.h>
 
-- 
2.20.1

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

[Marc Zyngier]

On 2020-07-30 07:14, Willy Tarreau wrote:
> On Thu, Jul 30, 2020 at 05:22:50AM +0200, Willy Tarreau wrote:
>> On Wed, Jul 29, 2020 at 08:17:48PM -0700, Kees Cook wrote:
>> > And just another heads-up, the patch[1] (which was never sent to a public
>> > list) also breaks arm64 (circular header needs?):
>> (...)
>> 
>> Definitely, we've just got a report about this, I'll have a look once
>> I'm at the office. I'd like to check that we don't obviously break
>> another arch by just removing percpu. If at least shuffling them 
>> around
>> is sufficient that'd be nice. Otherwise we'll likely need a separate
>> header (which is not a bad thing for the long term).
> 
> So Linus proposed a clean solution which might be harder to backport
> but looks better for 5.8. However the attached one addresses the issue
> for me on arm64 and still works on x86_64, arm, mips. I think we should
> go with this one first then apply Linus' one on top of it to be long
> term proof, and backport only the first one. Linus ?

So for what it's worth, this patch fixes the arm64 compilation problem
for me:

Tested-by: Marc Zyngier <maz@kernel.org>

I had come up with a different fix, only touching arm64 (see below).

Thanks,

         M.

 From 33d819f4efa0a4474b5dc2e4bcaef1b886ca30c3 Mon Sep 17 00:00:00 2001
 From: Marc Zyngier <maz@kernel.org>
Date: Thu, 30 Jul 2020 10:53:05 +0100
Subject: [PATCH] arm64: Drop unnecessary include from asm/smp.h

asm/pointer_auth.h is not needed anymore in asm/smp.h, as 62a679cb2825
("arm64: simplify ptrauth initialization") removed the keys from the
secondary_data structure.

This also cures a compilation issue introduced by f227e3ec3b5c
("random32: update the net random state on interrupt and activity").

Fixes: 62a679cb2825 ("arm64: simplify ptrauth initialization")
Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt 
and activity")
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
  arch/arm64/include/asm/smp.h | 1 -
  1 file changed, 1 deletion(-)

diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index ea268d88b6f7..a0c8a0b65259 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -30,7 +30,6 @@
  #include <linux/threads.h>
  #include <linux/cpumask.h>
  #include <linux/thread_info.h>
-#include <asm/pointer_auth.h>

  DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);

-- 
2.27.0


-- 
Who you jivin' with that Cosmik Debris?

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

[Catalin Marinas]

On Thu, Jul 30, 2020 at 10:59:09AM +0100, Marc Zyngier wrote:
> From 33d819f4efa0a4474b5dc2e4bcaef1b886ca30c3 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz@kernel.org>
> Date: Thu, 30 Jul 2020 10:53:05 +0100
> Subject: [PATCH] arm64: Drop unnecessary include from asm/smp.h
> 
> asm/pointer_auth.h is not needed anymore in asm/smp.h, as 62a679cb2825
> ("arm64: simplify ptrauth initialization") removed the keys from the
> secondary_data structure.
> 
> This also cures a compilation issue introduced by f227e3ec3b5c
> ("random32: update the net random state on interrupt and activity").
> 
> Fixes: 62a679cb2825 ("arm64: simplify ptrauth initialization")
> Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and
> activity")
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  arch/arm64/include/asm/smp.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index ea268d88b6f7..a0c8a0b65259 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -30,7 +30,6 @@
>  #include <linux/threads.h>
>  #include <linux/cpumask.h>
>  #include <linux/thread_info.h>
> -#include <asm/pointer_auth.h>
> 
>  DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);

I think this arm64 patch makes sense irrespective of any other generic
fixes. If Will wants to take it as a fix:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

(otherwise I'll queue it for 5.9)

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

[Will Deacon]

On Thu, Jul 30, 2020 at 11:09:23AM +0100, Catalin Marinas wrote:
> On Thu, Jul 30, 2020 at 10:59:09AM +0100, Marc Zyngier wrote:
> > From 33d819f4efa0a4474b5dc2e4bcaef1b886ca30c3 Mon Sep 17 00:00:00 2001
> > From: Marc Zyngier <maz@kernel.org>
> > Date: Thu, 30 Jul 2020 10:53:05 +0100
> > Subject: [PATCH] arm64: Drop unnecessary include from asm/smp.h
> > 
> > asm/pointer_auth.h is not needed anymore in asm/smp.h, as 62a679cb2825
> > ("arm64: simplify ptrauth initialization") removed the keys from the
> > secondary_data structure.
> > 
> > This also cures a compilation issue introduced by f227e3ec3b5c
> > ("random32: update the net random state on interrupt and activity").
> > 
> > Fixes: 62a679cb2825 ("arm64: simplify ptrauth initialization")
> > Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and
> > activity")
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/include/asm/smp.h | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> > index ea268d88b6f7..a0c8a0b65259 100644
> > --- a/arch/arm64/include/asm/smp.h
> > +++ b/arch/arm64/include/asm/smp.h
> > @@ -30,7 +30,6 @@
> >  #include <linux/threads.h>
> >  #include <linux/cpumask.h>
> >  #include <linux/thread_info.h>
> > -#include <asm/pointer_auth.h>
> > 
> >  DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
> 
> I think this arm64 patch makes sense irrespective of any other generic
> fixes. If Will wants to take it as a fix:
> 
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> (otherwise I'll queue it for 5.9)

Cheers, I'll pick this up asap.

Will

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

[Kees Cook]

On Thu, Jul 30, 2020 at 08:14:07AM +0200, Willy Tarreau wrote:
> On Thu, Jul 30, 2020 at 05:22:50AM +0200, Willy Tarreau wrote:
> > On Wed, Jul 29, 2020 at 08:17:48PM -0700, Kees Cook wrote:
> > > And just another heads-up, the patch[1] (which was never sent to a public
> > > list) also breaks arm64 (circular header needs?):
> > (...)
> > 
> > Definitely, we've just got a report about this, I'll have a look once
> > I'm at the office. I'd like to check that we don't obviously break
> > another arch by just removing percpu. If at least shuffling them around
> > is sufficient that'd be nice. Otherwise we'll likely need a separate
> > header (which is not a bad thing for the long term).
> 
> So Linus proposed a clean solution which might be harder to backport
> but looks better for 5.8. However the attached one addresses the issue
> for me on arm64 and still works on x86_64, arm, mips. I think we should
> go with this one first then apply Linus' one on top of it to be long
> term proof, and backport only the first one. Linus ?
> 
> Willy

> From 18fba9e2dfb16605a722e01f95d9e2d020efaa42 Mon Sep 17 00:00:00 2001
> From: Willy Tarreau <w@1wt.eu>
> Date: Thu, 30 Jul 2020 07:59:24 +0200
> Subject: random: fix circular include dependency on arm64 after addition of
>  percpu.h
> MIME-Version: 1.0
> Content-Type: text/plain; charset=latin1
> Content-Transfer-Encoding: 8bit
> 
> Daniel Díaz and Kees Cook independently reported that commit f227e3ec3b5c
> ("random32: update the net random state on interrupt and activity") broke
> arm64 due to a circular dependency on include files since the addition of
> percpu.h in random.h.
> 
> The correct fix would definitely be to move all the prandom32 stuff out
> of random.h but for backporting, a smaller solution is preferred. This
> one replaces linux/percpu.h with asm/percpu.h, and this fixes the problem
> on x86_64, arm64, arm, and mips. Note that moving percpu.h around didn't
> change anything and that removing it entirely broke differently. When
> backporting, such options might still be considered if this patch fails
> to help.
> 
> Reported-by: Daniel Díaz <daniel.diaz@linaro.org>
> Reported-by: Kees Cook <keescook@chromium.org>

FWIW, I was only a messenger. Sami (in Cc) pointed it out to me right
before I got the email from Linus for the x86 plugin breakage. :)

But yes, thanks, this seems to work for me.

> Fixes: f227e3ec3b5c

nit:

Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity")

-Kees

> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
>  include/linux/random.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/random.h b/include/linux/random.h
> index f310897f051d..9ab7443bd91b 100644
> --- a/include/linux/random.h
> +++ b/include/linux/random.h
> @@ -11,7 +11,7 @@
>  #include <linux/kernel.h>
>  #include <linux/list.h>
>  #include <linux/once.h>
> -#include <linux/percpu.h>
> +#include <asm/percpu.h>
>  
>  #include <uapi/linux/random.h>
>  
> -- 
> 2.20.1
> 


-- 
Kees Cook

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

[Linus Torvalds]

On Wed, Jul 29, 2020 at 8:17 PM Kees Cook <keescook@chromium.org> wrote:
>
> I'll look into this more tomorrow. (But yes, __latent_entropy is
> absolutely used for globals already, as you found, but this is the first
> percpu it was applied to...)

Note that it was always per-cpu.

The only thing that changed was that it was declared static in
lib/random.c vs being externally visible.

So it's not about the percpu part - although that then showed the
arm64 circular include file problem. It's literally that now the exact
same thing is declared in a header file and not marked "static".

Now, I don't think the __latent_entropy code ever really worked all
that well for per-cpu initializations. It ends up generating one
single initializer, which obviously isn't optimal. But I guess it's as
good as it gets.

Unrelated side note: I notice that the plugins could be simplified a
bit now that we require gcc 4.9 or later. There's a fair amount of
cruft for the earlier gcc versions.

I'm not sure how seriously the gcc plugins are actually maintained (no
offense) aside from just keeping them limping along. Does anybody
actually use them in production? I thought google had mostly moved on
to clang.

                Linus

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

[Kees Cook]

On Thu, Jul 30, 2020 at 11:24:44AM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 8:17 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > I'll look into this more tomorrow. (But yes, __latent_entropy is
> > absolutely used for globals already, as you found, but this is the first
> > percpu it was applied to...)
> 
> Note that it was always per-cpu.
> 
> The only thing that changed was that it was declared static in
> lib/random.c vs being externally visible.

Yup, thanks. I realized that a bit after sending my email. :)

> Unrelated side note: I notice that the plugins could be simplified a
> bit now that we require gcc 4.9 or later. There's a fair amount of
> cruft for the earlier gcc versions.

Yup -- Masahiro keeps poking the build system, but I haven't cleaned up
the header file macros to keep up with the recent jumps. (It falls a bit
low on my TODO list since it's a bit of a mechanical cleanup. I'm open
to anyone that would like to send patches, though!)

> I'm not sure how seriously the gcc plugins are actually maintained (no
> offense) aside from just keeping them limping along. Does anybody
> actually use them in production? I thought google had mostly moved on
> to clang.

They're part of regular testing, and there is ongoing development
(e.g. see Alex Popov's recent series[1], which is in -next waiting for
the v5.9 merge window). I hear regularly from folks using randstruct,
stackleak, structleak, and latent_entropy. But yes, Google has moved
to Clang where we're using Clang's implementation of structleak
(auto-var-init) but there has been work to get randstruct ported (as
desired by at least one Android vendor), though it's currently stalled.

-Kees

[1] https://lore.kernel.org/lkml/20200624123330.83226-1-alex.popov@linux.com/

-- 
Kees Cook

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

After merging the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

kernel/module.c: In function 'do_init_module':
kernel/module.c:3593:2: error: implicit declaration of function 'module_enable_ro'; did you mean 'module_enable_x'? [-Werror=implicit-function-declaration]
 3593 |  module_enable_ro(mod, true);
      |  ^~~~~~~~~~~~~~~~
      |  module_enable_x

Caused by commit

  e6eff4376e28 ("module: Make module_enable_ro() static again")

This config has neither CONFIG_ARCH_HAS_STRICT_MODULE_RWX or
CONFIG_ARCH_HAS_STRICT_MODULE_RWX set.  This failure was hidden in
linux-next due to commit

  db991af02f11 ("module: break nested ARCH_HAS_STRICT_MODULE_RWX and STRICT_MODULE_RWX #ifdefs")

from the modules tree. I have cherry-picked that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Josh Poimboeuf]

On Fri, Jun 05, 2020 at 08:37:15AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the origin tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/module.c: In function 'do_init_module':
> kernel/module.c:3593:2: error: implicit declaration of function 'module_enable_ro'; did you mean 'module_enable_x'? [-Werror=implicit-function-declaration]
>  3593 |  module_enable_ro(mod, true);
>       |  ^~~~~~~~~~~~~~~~
>       |  module_enable_x
> 
> Caused by commit
> 
>   e6eff4376e28 ("module: Make module_enable_ro() static again")
> 
> This config has neither CONFIG_ARCH_HAS_STRICT_MODULE_RWX or
> CONFIG_ARCH_HAS_STRICT_MODULE_RWX set.  This failure was hidden in
> linux-next due to commit
> 
>   db991af02f11 ("module: break nested ARCH_HAS_STRICT_MODULE_RWX and STRICT_MODULE_RWX #ifdefs")
> 
> from the modules tree. I have cherry-picked that commit for today.

Sorry, I guessed we missed that dependency between the live-patching and
module trees.

Jessica, are you planning on sending a pull request?

-- 
Josh

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

[Jessica Yu]

+++ Josh Poimboeuf [04/06/20 19:04 -0500]:
>On Fri, Jun 05, 2020 at 08:37:15AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the origin tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> kernel/module.c: In function 'do_init_module':
>> kernel/module.c:3593:2: error: implicit declaration of function 'module_enable_ro'; did you mean 'module_enable_x'? [-Werror=implicit-function-declaration]
>>  3593 |  module_enable_ro(mod, true);
>>       |  ^~~~~~~~~~~~~~~~
>>       |  module_enable_x
>>
>> Caused by commit
>>
>>   e6eff4376e28 ("module: Make module_enable_ro() static again")
>>
>> This config has neither CONFIG_ARCH_HAS_STRICT_MODULE_RWX or
>> CONFIG_ARCH_HAS_STRICT_MODULE_RWX set.  This failure was hidden in
>> linux-next due to commit
>>
>>   db991af02f11 ("module: break nested ARCH_HAS_STRICT_MODULE_RWX and STRICT_MODULE_RWX #ifdefs")
>>
>> from the modules tree. I have cherry-picked that commit for today.
>
>Sorry, I guessed we missed that dependency between the live-patching and
>module trees.
>
>Jessica, are you planning on sending a pull request?

Yep, just sent. So hopefully this gets resolved in the next day or two.

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

[reported by the kernelci.org bot]

The following error occurs in Linus' tree, build (riscv allnoconfig):

arch/riscv/kernel/stacktrace.c:78:8: error: ‘sp_in_global’ undeclared (first use in this function); did you mean ‘spin_lock’?

Caused by commit

  52e7c52d2ded ("RISC-V: Stop relying on GCC's register allocator's hueristics")

-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi all,

[At Michael's suggestion I have started doing htmldocs builds at the
end of linux-next runs.  Unfortunately, this currently fails for Linus'
tree.]

In Linus' tree, today's linux-next build (htmldocs) failed like this:

docutils.utils.SystemMessage: Documentation/driver-api/thermal/cpu-idle-cooling.rst:69: (SEVERE/4) Unexpected section title.

Caused by commit

  0a1990a2d1f2 ("thermal/drivers/cpu_cooling: Add idle cooling device documentation")

-- 
Cheers,
Stephen Rothwell

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

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

[Randy Dunlap]

On 1/30/20 8:12 PM, Stephen Rothwell wrote:
> Hi all,
> 
> [At Michael's suggestion I have started doing htmldocs builds at the
> end of linux-next runs.  Unfortunately, this currently fails for Linus'
> tree.]
> 
> In Linus' tree, today's linux-next build (htmldocs) failed like this:
> 
> docutils.utils.SystemMessage: Documentation/driver-api/thermal/cpu-idle-cooling.rst:69: (SEVERE/4) Unexpected section title.
> 
> Caused by commit
> 
>   0a1990a2d1f2 ("thermal/drivers/cpu_cooling: Add idle cooling device documentation")
> 


I sent a patch for that on 2020-JAN-20 but no one has replied to the patch:

https://lore.kernel.org/linux-pm/712c1152-56b5-307f-b3f3-ed03a30b804a@infradead.org/


-- 
~Randy

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

[Daniel Lezcano]

On 31/01/2020 05:17, Randy Dunlap wrote:
> On 1/30/20 8:12 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> [At Michael's suggestion I have started doing htmldocs builds at the
>> end of linux-next runs.  Unfortunately, this currently fails for Linus'
>> tree.]
>>
>> In Linus' tree, today's linux-next build (htmldocs) failed like this:
>>
>> docutils.utils.SystemMessage: Documentation/driver-api/thermal/cpu-idle-cooling.rst:69: (SEVERE/4) Unexpected section title.
>>
>> Caused by commit
>>
>>   0a1990a2d1f2 ("thermal/drivers/cpu_cooling: Add idle cooling device documentation")
>>
> 
> 
> I sent a patch for that on 2020-JAN-20 but no one has replied to the patch:
> 
> https://lore.kernel.org/linux-pm/712c1152-56b5-307f-b3f3-ed03a30b804a@infradead.org/

Right, sorry for that. I'll pick it and send a PR.

Thanks for the fix.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi Linus,

In Linus' tree, today's linux-next build (powerpc ppc64_defconfig) failed
like this:

arch/powerpc/platforms/pseries/hotplug-memory.c: In function 'pseries_remove_memblock':
arch/powerpc/platforms/pseries/hotplug-memory.c:103:17: error: unused variable 'pfn' [-Werror=unused-variable]

Caused by commit d760afd4d257 ("memory-hotplug: suppress "Trying to free
nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning").

I can't see what the point of the "pfn" variable is and this patch never
appeared in linux-next before being merged.  :-(

I have reverted that commit for today.

If this patch truly was authored yesterday (according the Author Date in
git), why was it merged yesterday while still under discussion?  And the
latest update to it still has this build problem ... did anyone even try
to build this for powerpc (since that architecture was obviously
affected)?  (Cross compilers available here
http://www.kernel.org/pub/tools/crosstool/).

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

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

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

[Andrew Morton]

On Wed, 10 Oct 2012 10:21:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Linus,
> 
> In Linus' tree, today's linux-next build (powerpc ppc64_defconfig) failed
> like this:
> 
> arch/powerpc/platforms/pseries/hotplug-memory.c: In function 'pseries_remove_memblock':
> arch/powerpc/platforms/pseries/hotplug-memory.c:103:17: error: unused variable 'pfn' [-Werror=unused-variable]
> 
> Caused by commit d760afd4d257 ("memory-hotplug: suppress "Trying to free
> nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning").
> 
> I can't see what the point of the "pfn" variable is

This:

--- a/arch/powerpc/platforms/pseries/hotplug-memory.c~a
+++ a/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -101,7 +101,7 @@ static int pseries_remove_memblock(unsig
 	sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
 	for (i = 0; i < sections_to_remove; i++) {
 		unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
-		ret = __remove_pages(zone, start_pfn,  PAGES_PER_SECTION);
+		ret = __remove_pages(zone, pfn, PAGES_PER_SECTION);
 		if (ret)
 			return ret;
 	}

> and this patch never
> appeared in linux-next before being merged.  :-(

It was first sighted October 3.

> I have reverted that commit for today.
> 
> If this patch truly was authored yesterday (according the Author Date in
> git), why was it merged yesterday while still under discussion?  And the
> latest update to it still has this build problem ... did anyone even try
> to build this for powerpc (since that architecture was obviously
> affected)?

Apparently not - the ppc bit was a best-effort fixup for a patch which
addresses an x86 problem.

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

[Yasuaki Ishimatsu]

Hi Stephen,

2012/10/10 8:45, Andrew Morton wrote:
> On Wed, 10 Oct 2012 10:21:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi Linus,
>>
>> In Linus' tree, today's linux-next build (powerpc ppc64_defconfig) failed
>> like this:
>>
>> arch/powerpc/platforms/pseries/hotplug-memory.c: In function 'pseries_remove_memblock':
>> arch/powerpc/platforms/pseries/hotplug-memory.c:103:17: error: unused variable 'pfn' [-Werror=unused-variable]
>>
>> Caused by commit d760afd4d257 ("memory-hotplug: suppress "Trying to free
>> nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning").
>>
>> I can't see what the point of the "pfn" variable is
>
> This:
>
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c~a
> +++ a/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -101,7 +101,7 @@ static int pseries_remove_memblock(unsig
>   	sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
>   	for (i = 0; i < sections_to_remove; i++) {
>   		unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
> -		ret = __remove_pages(zone, start_pfn,  PAGES_PER_SECTION);
> +		ret = __remove_pages(zone, pfn, PAGES_PER_SECTION);
>   		if (ret)
>   			return ret;
>   	}

I believe the error to be fixed with this patch.
Could you try it?

Thanks,
Yasuaki Ishimatsu

>
>> and this patch never
>> appeared in linux-next before being merged.  :-(
>
> It was first sighted October 3.
>
>> I have reverted that commit for today.
>>
>> If this patch truly was authored yesterday (according the Author Date in
>> git), why was it merged yesterday while still under discussion?  And the
>> latest update to it still has this build problem ... did anyone even try
>> to build this for powerpc (since that architecture was obviously
>> affected)?
>
> Apparently not - the ppc bit was a best-effort fixup for a patch which
> addresses an x86 problem.
>

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

[Stephen Rothwell]

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

Hi,

On Wed, 10 Oct 2012 08:52:21 +0900 Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> wrote:
>
> 2012/10/10 8:45, Andrew Morton wrote:
> > On Wed, 10 Oct 2012 10:21:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Hi Linus,
> >>
> >> In Linus' tree, today's linux-next build (powerpc ppc64_defconfig) failed
> >> like this:
> >>
> >> arch/powerpc/platforms/pseries/hotplug-memory.c: In function 'pseries_remove_memblock':
> >> arch/powerpc/platforms/pseries/hotplug-memory.c:103:17: error: unused variable 'pfn' [-Werror=unused-variable]
> >>
> >> Caused by commit d760afd4d257 ("memory-hotplug: suppress "Trying to free
> >> nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning").
> >>
> >> I can't see what the point of the "pfn" variable is
> >
> > This:
> >
> > --- a/arch/powerpc/platforms/pseries/hotplug-memory.c~a
> > +++ a/arch/powerpc/platforms/pseries/hotplug-memory.c
> > @@ -101,7 +101,7 @@ static int pseries_remove_memblock(unsig
> >   	sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
> >   	for (i = 0; i < sections_to_remove; i++) {
> >   		unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
> > -		ret = __remove_pages(zone, start_pfn,  PAGES_PER_SECTION);
> > +		ret = __remove_pages(zone, pfn, PAGES_PER_SECTION);
> >   		if (ret)
> >   			return ret;
> >   	}
> 
> I believe the error to be fixed with this patch.
> Could you try it?

The certainly fixes the build problem.  I can't comment in the semantics
of the patch.

Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>  (Build only)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

[Stephen Rothwell]

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

Hi Andrew,

On Tue, 9 Oct 2012 16:45:14 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 10 Oct 2012 10:21:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > I can't see what the point of the "pfn" variable is
> 
> This:
> 
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c~a
> +++ a/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -101,7 +101,7 @@ static int pseries_remove_memblock(unsig
>  	sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
>  	for (i = 0; i < sections_to_remove; i++) {
>  		unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
> -		ret = __remove_pages(zone, start_pfn,  PAGES_PER_SECTION);
> +		ret = __remove_pages(zone, pfn, PAGES_PER_SECTION);
>  		if (ret)
>  			return ret;
>  	}

Can we get that fix to Linus ASAP, please?

> > and this patch never
> > appeared in linux-next before being merged.  :-(
> 
> It was first sighted October 3.

Yeah, my mistake. But it never made it to linux-next.

> > I have reverted that commit for today.
> > 
> > If this patch truly was authored yesterday (according the Author Date in
> > git), why was it merged yesterday while still under discussion?  And the
> > latest update to it still has this build problem ... did anyone even try
> > to build this for powerpc (since that architecture was obviously
> > affected)?
> 
> Apparently not - the ppc bit was a best-effort fixup for a patch which
> addresses an x86 problem.

Right, and that is one of the reasons we have linux-next - to test for
cross architecture problems.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi Al,

Building the origin tree (v3.5-rc1 sh lboxre2_defconfig and other sh
configs) failed like this:

arch/sh/include/asm/thread_info.h:172:2: error: 'TAINT_WARN' undeclared (first use in this function)

Caused by commit edd63a2763bd ("set_restore_sigmask() is never called
without SIGPENDING (and never should be)").  Missing include of kernel.h.

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

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

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

[Paul Mundt]

On Mon, Jun 04, 2012 at 12:57:24PM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> Building the origin tree (v3.5-rc1 sh lboxre2_defconfig and other sh
> configs) failed like this:
> 
> arch/sh/include/asm/thread_info.h:172:2: error: 'TAINT_WARN' undeclared (first use in this function)
> 
> Caused by commit edd63a2763bd ("set_restore_sigmask() is never called
> without SIGPENDING (and never should be)").  Missing include of kernel.h.
> 
Ideally bug.h should be including linux/kernel.h itself due to its
TAINT_WARN dependence, it just seems to be getting lucky on other
platforms who either don't have this combination or pull in kernel.h from
somewhere else.

That commit also introduces a linux/bug.h include for WARN_ON() in
linux/thread_info.h which would be similarly insufficient for any
TIF_RESTORE_SIGMASK && !HAVE_SET_RESTORE_SIGMASK platform that also uses
asm-generic/bug.h. 

Given that, I'd prefer stuffing the include in asm-generic directly:

---

bug.h: need linux/kernel.h for TAINT_WARN.

asm-generic/bug.h uses taint flags that are only defined in
linux/kernel.h, resulting in build failures on platforms that
don't include linux/kernel.h some other way:

	arch/sh/include/asm/thread_info.h:172:2: error: 'TAINT_WARN' undeclared (first use in this function)

Caused by commit edd63a2763bd ("set_restore_sigmask() is never called
without SIGPENDING (and never should be)").

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

---

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 2520a6e..9f02005 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -2,6 +2,7 @@
 #define _ASM_GENERIC_BUG_H
 
 #include <linux/compiler.h>
+#include <linux/kernel.h>
 
 #ifdef CONFIG_BUG
 

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

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

Hi Linus,

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

ERROR: "xen_biovec_phys_mergeable" [drivers/block/nvme.ko] undefined!

This is weird, as CONFIG_BLOCK and CONFIG_XEN are both set in this build
and I started with an empty object directory.  And biomerge.o has been
built.

Ah ha!

drivers/xen/biomerge.c:14:1: warning: data definition has no type or storage class [enabled by default]
drivers/xen/biomerge.c:14:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Wimplicit-int]
drivers/xen/biomerge.c:14:1: warning: parameter names (without types) in function declaration [enabled by default]

drivers/xen/biomerge.c does not include export.h.  It would be nice if
this produced an error, not just the warnings above.  Caused by commit
0b934ccd707f ("Xen: Export xen_biovec_phys_mergeable") (which was never
in linux-next :-().

I applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 19 Jan 2012 10:24:31 +1100
Subject: [PATCH] xen: using EXPORT_SYMBOL requires including export.h

Fixes these warnings:

drivers/xen/biomerge.c:14:1: warning: data definition has no type or storage class [enabled by default]
drivers/xen/biomerge.c:14:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Wimplicit-int]
drivers/xen/biomerge.c:14:1: warning: parameter names (without types) in function declaration [enabled by default]

And this build error:

ERROR: "xen_biovec_phys_mergeable" [drivers/block/nvme.ko] undefined!

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

diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
index 18c1bb6..0edb91c 100644
--- a/drivers/xen/biomerge.c
+++ b/drivers/xen/biomerge.c
@@ -1,5 +1,6 @@
 #include <linux/bio.h>
 #include <linux/io.h>
+#include <linux/export.h>
 #include <xen/page.h>
 
 bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
-- 
1.7.9.rc0.23.g7e521

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

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

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

[Jens Axboe]

On 01/19/2012 12:31 AM, Stephen Rothwell wrote:
> Hi Linus,
> 
> After merging the origin tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "xen_biovec_phys_mergeable" [drivers/block/nvme.ko] undefined!
> 
> This is weird, as CONFIG_BLOCK and CONFIG_XEN are both set in this build
> and I started with an empty object directory.  And biomerge.o has been
> built.
> 
> Ah ha!
> 
> drivers/xen/biomerge.c:14:1: warning: data definition has no type or storage class [enabled by default]
> drivers/xen/biomerge.c:14:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Wimplicit-int]
> drivers/xen/biomerge.c:14:1: warning: parameter names (without types) in function declaration [enabled by default]
> 
> drivers/xen/biomerge.c does not include export.h.  It would be nice if
> this produced an error, not just the warnings above.  Caused by commit
> 0b934ccd707f ("Xen: Export xen_biovec_phys_mergeable") (which was never
> in linux-next :-().
> 
> I applied the following patch for today:

Thanks Stephen, applied.

-- 
Jens Axboe

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

[Jens Axboe]

On 01/19/2012 09:21 AM, Jens Axboe wrote:
> On 01/19/2012 12:31 AM, Stephen Rothwell wrote:
>> Hi Linus,
>>
>> After merging the origin tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> ERROR: "xen_biovec_phys_mergeable" [drivers/block/nvme.ko] undefined!
>>
>> This is weird, as CONFIG_BLOCK and CONFIG_XEN are both set in this build
>> and I started with an empty object directory.  And biomerge.o has been
>> built.
>>
>> Ah ha!
>>
>> drivers/xen/biomerge.c:14:1: warning: data definition has no type or storage class [enabled by default]
>> drivers/xen/biomerge.c:14:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Wimplicit-int]
>> drivers/xen/biomerge.c:14:1: warning: parameter names (without types) in function declaration [enabled by default]
>>
>> drivers/xen/biomerge.c does not include export.h.  It would be nice if
>> this produced an error, not just the warnings above.  Caused by commit
>> 0b934ccd707f ("Xen: Export xen_biovec_phys_mergeable") (which was never
>> in linux-next :-().
>>
>> I applied the following patch for today:
> 
> Thanks Stephen, applied.

Already in, even better :-)

-- 
Jens Axboe

linux-next: build failure after merge of the origin tree

[Stephen Rothwell]

Hi Linus,

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

ERROR: "__bad_udelay" [drivers/staging/gma500/psb_gfx.ko] undefined!

Presumably caused by commit a87e553fabe8 ("asm-generic: delay.h fix
udelay and ndelay for 8 bit args").
drivers/staging/gma500/psb_intel_display.c has a udelay
(20000) which is explicitly disallowed by this patch.

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 Jul 2011 11:13:13 +1000
Subject: [PATCH] gma500: udlay(20000) is too large

So we use mdelay(20) instead.  Fixes this build error:

ERROR: "__bad_udelay" [drivers/staging/gma500/psb_gfx.ko] undefined!

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/gma500/psb_intel_display.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/gma500/psb_intel_display.c b/drivers/staging/gma500/psb_intel_display.c
index 4f47d09..09e378d 100644
--- a/drivers/staging/gma500/psb_intel_display.c
+++ b/drivers/staging/gma500/psb_intel_display.c
@@ -331,7 +331,7 @@ static bool psb_intel_find_best_PLL(struct drm_crtc *crtc, int target,
 void psb_intel_wait_for_vblank(struct drm_device *dev)
 {
 	/* Wait for 20ms, i.e. one cycle at 50hz. */
-	udelay(20000);
+	mdelay(20);
 }
 
 int psb_intel_pipe_set_base(struct drm_crtc *crtc,
-- 
1.7.5.4


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/