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

[Stephen Rothwell]

Hi Ingo,

On Tue, 1 Mar 2016 08:07:50 +0100 Ingo Molnar  wrote:
>
> > This build is done with a PowerPC hosted cross compiler with no glibc.  
> 
> Ugh, what a rare and weird way to build an x86 kernel, and you made 
> linux-next 
> dependent on it?

It is just the fastest hardware I currently have access to (you remember
who I work for, right? ;-)).  I have always done at least part of the
linux-next building (daily, or overnight) on PowerPC hardware and this
is only the 2nd or third time in over 8 years that it has found an
issue like this.

> > I assume that some things here need to be built with HOSTCC?  
> 
> I suspect that's the culprit.

Good, hopefully it is not too hard to fix.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Ingo,

On Tue, 1 Mar 2016 08:07:50 +0100 Ingo Molnar  wrote:
>
> > This build is done with a PowerPC hosted cross compiler with no glibc.  
> 
> Ugh, what a rare and weird way to build an x86 kernel, and you made 
> linux-next 
> dependent on it?

It is just the fastest hardware I currently have access to (you remember
who I work for, right? ;-)).  I have always done at least part of the
linux-next building (daily, or overnight) on PowerPC hardware and this
is only the 2nd or third time in over 8 years that it has found an
issue like this.

> > I assume that some things here need to be built with HOSTCC?  
> 
> I suspect that's the culprit.

Good, hopefully it is not too hard to fix.

-- 
Cheers,
Stephen Rothwell

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

[Sedat Dilek]

On Tue, Mar 1, 2016 at 8:39 AM, H. Peter Anvin  wrote:
> On February 29, 2016 11:28:22 PM PST, Sedat Dilek  
> wrote:
>>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar  wrote:
>>>
>>> * Stephen Rothwell  wrote:
>>>
 Hi all,

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

   DESCEND  objtool
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
   MKDIR
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
 elf.c:22:23: fatal error: sys/types.h: No such file or directory
 compilation terminated.
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
 builtin-check.c:28:20: fatal error: string.h: No such file or
>>directory
 compilation terminated.
 objtool.c:28:19: fatal error: stdio.h: No such file or directory
 compilation terminated.

 and further errors ...

 This build is done with a PowerPC hosted cross compiler with no
>>glibc.
>>>
>>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>>linux-next
>>> dependent on it?
>>>
 I assume that some things here need to be built with HOSTCC?
>>>
>>> I suspect that's the culprit. Do you now mandate people to have
>>PowerPC systems as
>>> a requirement to merge to linux-next? How are people supposed to be
>>able to test
>>> that rare type of build method which does not matter to 99.99% of our
>>kernel
>>> testers and users?
>>>
>>
> >From my experience in using different $COMPILER you should always pass
>>CC and HOSTCC in your make-line when building a Linux-kernel or
>>playing with the Kconfig-system.
>>
>>When building my llvm-toolchain with make/autoconf I had also to pass
>>CC and CXX to my configure-line otherwise you got misconfiguration.
>>
>>[ EXAMPLE: Linux Kconfig-system ]
>>
>>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>>HOSTCC=$COMPILER"
>>
>>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>>silentoldconfig < /dev/null
>>
>>- Sedat -
>
> That is not the issue here.  The problem is clearly that objtool is a host 
> program and not compiled with host cc.  So it is a good thing to test even 
> though it is weird, because it affects real use cases.
>
> As x86 is far and beyond the most widely used host architecture, 
> cross-compiling x86 is more likely to involve compiler differences than 
> actually using another host, or possibly compiling 32 bits on a system 
> without the 32-bit libc installed, but it should still work.
>

Thanks for the clarification.

I talked about my experiences in software building in general.

When this is a "tools/objtool problem" then someone should address
this to "tools/objtool maintainers/folks" or whoever else is
responsible.

- Sedat -

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

[Sedat Dilek]

On Tue, Mar 1, 2016 at 8:39 AM, H. Peter Anvin  wrote:
> On February 29, 2016 11:28:22 PM PST, Sedat Dilek  
> wrote:
>>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar  wrote:
>>>
>>> * Stephen Rothwell  wrote:
>>>
 Hi all,

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

   DESCEND  objtool
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
   MKDIR
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
 elf.c:22:23: fatal error: sys/types.h: No such file or directory
 compilation terminated.
   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
 builtin-check.c:28:20: fatal error: string.h: No such file or
>>directory
 compilation terminated.
 objtool.c:28:19: fatal error: stdio.h: No such file or directory
 compilation terminated.

 and further errors ...

 This build is done with a PowerPC hosted cross compiler with no
>>glibc.
>>>
>>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>>linux-next
>>> dependent on it?
>>>
 I assume that some things here need to be built with HOSTCC?
>>>
>>> I suspect that's the culprit. Do you now mandate people to have
>>PowerPC systems as
>>> a requirement to merge to linux-next? How are people supposed to be
>>able to test
>>> that rare type of build method which does not matter to 99.99% of our
>>kernel
>>> testers and users?
>>>
>>
> >From my experience in using different $COMPILER you should always pass
>>CC and HOSTCC in your make-line when building a Linux-kernel or
>>playing with the Kconfig-system.
>>
>>When building my llvm-toolchain with make/autoconf I had also to pass
>>CC and CXX to my configure-line otherwise you got misconfiguration.
>>
>>[ EXAMPLE: Linux Kconfig-system ]
>>
>>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>>HOSTCC=$COMPILER"
>>
>>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>>silentoldconfig < /dev/null
>>
>>- Sedat -
>
> That is not the issue here.  The problem is clearly that objtool is a host 
> program and not compiled with host cc.  So it is a good thing to test even 
> though it is weird, because it affects real use cases.
>
> As x86 is far and beyond the most widely used host architecture, 
> cross-compiling x86 is more likely to involve compiler differences than 
> actually using another host, or possibly compiling 32 bits on a system 
> without the 32-bit libc installed, but it should still work.
>

Thanks for the clarification.

I talked about my experiences in software building in general.

When this is a "tools/objtool problem" then someone should address
this to "tools/objtool maintainers/folks" or whoever else is
responsible.

- Sedat -

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

[H. Peter Anvin]

On February 29, 2016 11:28:22 PM PST, Sedat Dilek  wrote:
>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar  wrote:
>>
>> * Stephen Rothwell  wrote:
>>
>>> Hi all,
>>>
>>> After merging the tip tree, today's linux-next build (x86_64
>allmodconfig)
>>> failed like this:
>>>
>>>   DESCEND  objtool
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>>   MKDIR   
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>> compilation terminated.
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>directory
>>> compilation terminated.
>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>> compilation terminated.
>>>
>>> and further errors ...
>>>
>>> This build is done with a PowerPC hosted cross compiler with no
>glibc.
>>
>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>linux-next
>> dependent on it?
>>
>>> I assume that some things here need to be built with HOSTCC?
>>
>> I suspect that's the culprit. Do you now mandate people to have
>PowerPC systems as
>> a requirement to merge to linux-next? How are people supposed to be
>able to test
>> that rare type of build method which does not matter to 99.99% of our
>kernel
>> testers and users?
>>
>
>From my experience in using different $COMPILER you should always pass
>CC and HOSTCC in your make-line when building a Linux-kernel or
>playing with the Kconfig-system.
>
>When building my llvm-toolchain with make/autoconf I had also to pass
>CC and CXX to my configure-line otherwise you got misconfiguration.
>
>[ EXAMPLE: Linux Kconfig-system ]
>
>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>HOSTCC=$COMPILER"
>
>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>silentoldconfig < /dev/null
>
>- Sedat -

That is not the issue here.  The problem is clearly that objtool is a host 
program and not compiled with host cc.  So it is a good thing to test even 
though it is weird, because it affects real use cases.

As x86 is far and beyond the most widely used host architecture, 
cross-compiling x86 is more likely to involve compiler differences than 
actually using another host, or possibly compiling 32 bits on a system without 
the 32-bit libc installed, but it should still work.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

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

[H. Peter Anvin]

On February 29, 2016 11:28:22 PM PST, Sedat Dilek  wrote:
>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar  wrote:
>>
>> * Stephen Rothwell  wrote:
>>
>>> Hi all,
>>>
>>> After merging the tip tree, today's linux-next build (x86_64
>allmodconfig)
>>> failed like this:
>>>
>>>   DESCEND  objtool
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>>   MKDIR   
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>> compilation terminated.
>>>   CC  
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>directory
>>> compilation terminated.
>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>> compilation terminated.
>>>
>>> and further errors ...
>>>
>>> This build is done with a PowerPC hosted cross compiler with no
>glibc.
>>
>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>linux-next
>> dependent on it?
>>
>>> I assume that some things here need to be built with HOSTCC?
>>
>> I suspect that's the culprit. Do you now mandate people to have
>PowerPC systems as
>> a requirement to merge to linux-next? How are people supposed to be
>able to test
>> that rare type of build method which does not matter to 99.99% of our
>kernel
>> testers and users?
>>
>
>From my experience in using different $COMPILER you should always pass
>CC and HOSTCC in your make-line when building a Linux-kernel or
>playing with the Kconfig-system.
>
>When building my llvm-toolchain with make/autoconf I had also to pass
>CC and CXX to my configure-line otherwise you got misconfiguration.
>
>[ EXAMPLE: Linux Kconfig-system ]
>
>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>HOSTCC=$COMPILER"
>
>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>silentoldconfig < /dev/null
>
>- Sedat -

That is not the issue here.  The problem is clearly that objtool is a host 
program and not compiled with host cc.  So it is a good thing to test even 
though it is weird, because it affects real use cases.

As x86 is far and beyond the most widely used host architecture, 
cross-compiling x86 is more likely to involve compiler differences than 
actually using another host, or possibly compiling 32 bits on a system without 
the 32-bit libc installed, but it should still work.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

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

[Sedat Dilek]

On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar  wrote:
>
> * Stephen Rothwell  wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>>   DESCEND  objtool
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>   MKDIR/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>> compilation terminated.
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>> builtin-check.c:28:20: fatal error: string.h: No such file or directory
>> compilation terminated.
>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>> compilation terminated.
>>
>> and further errors ...
>>
>> This build is done with a PowerPC hosted cross compiler with no glibc.
>
> Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next
> dependent on it?
>
>> I assume that some things here need to be built with HOSTCC?
>
> I suspect that's the culprit. Do you now mandate people to have PowerPC 
> systems as
> a requirement to merge to linux-next? How are people supposed to be able to 
> test
> that rare type of build method which does not matter to 99.99% of our kernel
> testers and users?
>

>From my experience in using different $COMPILER you should always pass
CC and HOSTCC in your make-line when building a Linux-kernel or
playing with the Kconfig-system.

When building my llvm-toolchain with make/autoconf I had also to pass
CC and CXX to my configure-line otherwise you got misconfiguration.

[ EXAMPLE: Linux Kconfig-system ]

$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
HOSTCC=$COMPILER"

$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
silentoldconfig < /dev/null

- Sedat -

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

[Sedat Dilek]

On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar  wrote:
>
> * Stephen Rothwell  wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>>   DESCEND  objtool
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>   MKDIR/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>> compilation terminated.
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>> builtin-check.c:28:20: fatal error: string.h: No such file or directory
>> compilation terminated.
>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>> compilation terminated.
>>
>> and further errors ...
>>
>> This build is done with a PowerPC hosted cross compiler with no glibc.
>
> Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next
> dependent on it?
>
>> I assume that some things here need to be built with HOSTCC?
>
> I suspect that's the culprit. Do you now mandate people to have PowerPC 
> systems as
> a requirement to merge to linux-next? How are people supposed to be able to 
> test
> that rare type of build method which does not matter to 99.99% of our kernel
> testers and users?
>

>From my experience in using different $COMPILER you should always pass
CC and HOSTCC in your make-line when building a Linux-kernel or
playing with the Kconfig-system.

When building my llvm-toolchain with make/autoconf I had also to pass
CC and CXX to my configure-line otherwise you got misconfiguration.

[ EXAMPLE: Linux Kconfig-system ]

$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
HOSTCC=$COMPILER"

$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
silentoldconfig < /dev/null

- Sedat -

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

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
>   DESCEND  objtool
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>   MKDIR/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
> elf.c:22:23: fatal error: sys/types.h: No such file or directory
> compilation terminated.
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
> builtin-check.c:28:20: fatal error: string.h: No such file or directory
> compilation terminated.
> objtool.c:28:19: fatal error: stdio.h: No such file or directory
> compilation terminated.
> 
> and further errors ...
> 
> This build is done with a PowerPC hosted cross compiler with no glibc.

Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next 
dependent on it?

> I assume that some things here need to be built with HOSTCC?

I suspect that's the culprit. Do you now mandate people to have PowerPC systems 
as 
a requirement to merge to linux-next? How are people supposed to be able to 
test 
that rare type of build method which does not matter to 99.99% of our kernel 
testers and users?

Thanks,

Ingo

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

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
>   DESCEND  objtool
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>   MKDIR/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
> elf.c:22:23: fatal error: sys/types.h: No such file or directory
> compilation terminated.
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>   CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
> builtin-check.c:28:20: fatal error: string.h: No such file or directory
> compilation terminated.
> objtool.c:28:19: fatal error: stdio.h: No such file or directory
> compilation terminated.
> 
> and further errors ...
> 
> This build is done with a PowerPC hosted cross compiler with no glibc.

Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next 
dependent on it?

> I assume that some things here need to be built with HOSTCC?

I suspect that's the culprit. Do you now mandate people to have PowerPC systems 
as 
a requirement to merge to linux-next? How are people supposed to be able to 
test 
that rare type of build method which does not matter to 99.99% of our kernel 
testers and users?

Thanks,

Ingo

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

[Stephen Rothwell]

Hi all,

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

  DESCEND  objtool
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
  MKDIR/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
elf.c:22:23: fatal error: sys/types.h: No such file or directory
compilation terminated.
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
builtin-check.c:28:20: fatal error: string.h: No such file or directory
compilation terminated.
objtool.c:28:19: fatal error: stdio.h: No such file or directory
compilation terminated.

and further errors ...

This build is done with a PowerPC hosted cross compiler with no glibc.
I assume that some things here need to be built with HOSTCC?

Presumably caused by commit

  9e54249679b4 ("Merge branch 'core/objtool'")

and the commit series that was merged.

I tried to revert that merge, but it had conflicts, so I just used the
tip tree from next-20160229 for today.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

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

  DESCEND  objtool
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
  MKDIR/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
elf.c:22:23: fatal error: sys/types.h: No such file or directory
compilation terminated.
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
  CC   /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
builtin-check.c:28:20: fatal error: string.h: No such file or directory
compilation terminated.
objtool.c:28:19: fatal error: stdio.h: No such file or directory
compilation terminated.

and further errors ...

This build is done with a PowerPC hosted cross compiler with no glibc.
I assume that some things here need to be built with HOSTCC?

Presumably caused by commit

  9e54249679b4 ("Merge branch 'core/objtool'")

and the commit series that was merged.

I tried to revert that merge, but it had conflicts, so I just used the
tip tree from next-20160229 for today.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Jiri,

On Wed, 30 Sep 2015 08:08:12 +0200 Jiri Olsa  wrote:
>
> ouch, forgot to CC you, sry

No worries, I was watching ...

> it won't fix the build if you still have old .cmd file in you tree (I presume 
> that's the case),
> once those are regenerated you shouldn't meet the issue again

Unfortunately this is what happens to me every day :-( (at least until
these changes are merged into Linus' tree).  Its fine, I have automated
the clean up of the perf build object directory after merging the tip
tree.  However, this will also happen to anyone who has built perf then
updates their tree and then tries to rebuild perf.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jiri Olsa]

On Wed, Sep 30, 2015 at 12:56:40PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell  
> wrote:
> >
> > On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa  wrote:
> > >
> > > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > > 
> > > > After merging the tip tree, today's linux-next build (perf) failed
> > > > like this:
> > > > 
> > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', 
> > > > needed by 'tools/perf/arch/common.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > > > 'tools/perf/fs/fs.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', 
> > > > needed by 'tools/perf/util/abspath.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > > Makefile:68: recipe for target 'all' failed
> > > > 
> > > > Maybe caused by commit
> > > > 
> > > >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > > > objects")
> > > > 
> > > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > > the build for each tree merge (in case that matters).
> > > 
> > > it does in this case, removed header files stay in
> > > cmd build dependency file (like in .abspath.o.cmd above)
> > > and cause build error
> > > 
> > > build system is not smart enough yet to find out,
> > > I was postponning fixing this for some time now,
> > > I'll try to get this resolved asap
> > 
> > OK, for now I will clean out my objdir before doing the perf build
> > after the tip tree merge.  It would be nice to have this fixed, though,
> > if possible.
> 
> I noticed some commits in the tip tree today that seemed as though they
> were addressing this problem.  However, I still get a build failure if
> I don't clean out the object directory before building tools/perf:

ouch, forgot to CC you, sry

> 
>   BUILD:   Doing 'make -j48' parallel build
>   GEN  /home/sfr/next/perf/common-cmds.h
>   CC   /home/sfr/next/perf/fixdep.o
>   LD   /home/sfr/next/perf/fixdep-in.o
>   LINK /home/sfr/next/perf/fixdep
>   CC   /home/sfr/next/perf/perf-read-vdso32
>   CC   /home/sfr/next/perf/perf-read-vdsox32
> make[3]: *** No rule to make target 
> '/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by 
> '/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
> /home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 
> 'ui/gtk' failed
> make[2]: *** [ui/gtk] Error 2
> Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

it won't fix the build if you still have old .cmd file in you tree (I presume 
that's the case),
once those are regenerated you shouldn't meet the issue again

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jiri Olsa]

On Wed, Sep 30, 2015 at 12:56:40PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell  
> wrote:
> >
> > On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa  wrote:
> > >
> > > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > > 
> > > > After merging the tip tree, today's linux-next build (perf) failed
> > > > like this:
> > > > 
> > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', 
> > > > needed by 'tools/perf/arch/common.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > > > 'tools/perf/fs/fs.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', 
> > > > needed by 'tools/perf/util/abspath.o'.  Stop.
> > > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > > Makefile:68: recipe for target 'all' failed
> > > > 
> > > > Maybe caused by commit
> > > > 
> > > >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > > > objects")
> > > > 
> > > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > > the build for each tree merge (in case that matters).
> > > 
> > > it does in this case, removed header files stay in
> > > cmd build dependency file (like in .abspath.o.cmd above)
> > > and cause build error
> > > 
> > > build system is not smart enough yet to find out,
> > > I was postponning fixing this for some time now,
> > > I'll try to get this resolved asap
> > 
> > OK, for now I will clean out my objdir before doing the perf build
> > after the tip tree merge.  It would be nice to have this fixed, though,
> > if possible.
> 
> I noticed some commits in the tip tree today that seemed as though they
> were addressing this problem.  However, I still get a build failure if
> I don't clean out the object directory before building tools/perf:

ouch, forgot to CC you, sry

> 
>   BUILD:   Doing 'make -j48' parallel build
>   GEN  /home/sfr/next/perf/common-cmds.h
>   CC   /home/sfr/next/perf/fixdep.o
>   LD   /home/sfr/next/perf/fixdep-in.o
>   LINK /home/sfr/next/perf/fixdep
>   CC   /home/sfr/next/perf/perf-read-vdso32
>   CC   /home/sfr/next/perf/perf-read-vdsox32
> make[3]: *** No rule to make target 
> '/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by 
> '/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
> /home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 
> 'ui/gtk' failed
> make[2]: *** [ui/gtk] Error 2
> Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

it won't fix the build if you still have old .cmd file in you tree (I presume 
that's the case),
once those are regenerated you shouldn't meet the issue again

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Jiri,

On Wed, 30 Sep 2015 08:08:12 +0200 Jiri Olsa  wrote:
>
> ouch, forgot to CC you, sry

No worries, I was watching ...

> it won't fix the build if you still have old .cmd file in you tree (I presume 
> that's the case),
> once those are regenerated you shouldn't meet the issue again

Unfortunately this is what happens to me every day :-( (at least until
these changes are merged into Linus' tree).  Its fine, I have automated
the clean up of the perf build object directory after merging the tip
tree.  However, this will also happen to anyone who has built perf then
updates their tree and then tries to rebuild perf.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell  
wrote:
>
> On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa  wrote:
> >
> > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (perf) failed
> > > like this:
> > > 
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed 
> > > by 'tools/perf/arch/common.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > > 'tools/perf/fs/fs.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed 
> > > by 'tools/perf/util/abspath.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > Makefile:68: recipe for target 'all' failed
> > > 
> > > Maybe caused by commit
> > > 
> > >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > > objects")
> > > 
> > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > the build for each tree merge (in case that matters).
> > 
> > it does in this case, removed header files stay in
> > cmd build dependency file (like in .abspath.o.cmd above)
> > and cause build error
> > 
> > build system is not smart enough yet to find out,
> > I was postponning fixing this for some time now,
> > I'll try to get this resolved asap
> 
> OK, for now I will clean out my objdir before doing the perf build
> after the tip tree merge.  It would be nice to have this fixed, though,
> if possible.

I noticed some commits in the tip tree today that seemed as though they
were addressing this problem.  However, I still get a build failure if
I don't clean out the object directory before building tools/perf:

  BUILD:   Doing 'make -j48' parallel build
  GEN  /home/sfr/next/perf/common-cmds.h
  CC   /home/sfr/next/perf/fixdep.o
  LD   /home/sfr/next/perf/fixdep-in.o
  LINK /home/sfr/next/perf/fixdep
  CC   /home/sfr/next/perf/perf-read-vdso32
  CC   /home/sfr/next/perf/perf-read-vdsox32
make[3]: *** No rule to make target 
'/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by 
'/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
/home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' 
failed
make[2]: *** [ui/gtk] Error 2
Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

(/home/sfr/next/perf/ is the object directory)
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

On Thu, 17 Sep 2015 10:34:23 +1000 Stephen Rothwell  
wrote:
>
> On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa  wrote:
> >
> > On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the tip tree, today's linux-next build (perf) failed
> > > like this:
> > > 
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed 
> > > by 'tools/perf/arch/common.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > > 'tools/perf/fs/fs.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed 
> > > by 'tools/perf/util/abspath.o'.  Stop.
> > > tools/build/Makefile.build:109: recipe for target 'util' failed
> > > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > > Makefile:68: recipe for target 'all' failed
> > > 
> > > Maybe caused by commit
> > > 
> > >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > > objects")
> > > 
> > > This is an incremental build i.e. I do not do a "make clean" after doing
> > > the build for each tree merge (in case that matters).
> > 
> > it does in this case, removed header files stay in
> > cmd build dependency file (like in .abspath.o.cmd above)
> > and cause build error
> > 
> > build system is not smart enough yet to find out,
> > I was postponning fixing this for some time now,
> > I'll try to get this resolved asap
> 
> OK, for now I will clean out my objdir before doing the perf build
> after the tip tree merge.  It would be nice to have this fixed, though,
> if possible.

I noticed some commits in the tip tree today that seemed as though they
were addressing this problem.  However, I still get a build failure if
I don't clean out the object directory before building tools/perf:

  BUILD:   Doing 'make -j48' parallel build
  GEN  /home/sfr/next/perf/common-cmds.h
  CC   /home/sfr/next/perf/fixdep.o
  LD   /home/sfr/next/perf/fixdep-in.o
  LINK /home/sfr/next/perf/fixdep
  CC   /home/sfr/next/perf/perf-read-vdso32
  CC   /home/sfr/next/perf/perf-read-vdsox32
make[3]: *** No rule to make target 
'/home/sfr/next/next/tools/lib/api/fs/debugfs.h', needed by 
'/home/sfr/next/perf/ui/gtk/browser.o'.  Stop.
/home/sfr/next/next/tools/build/Makefile.build:116: recipe for target 'ui/gtk' 
failed
make[2]: *** [ui/gtk] Error 2
Makefile.perf:310: recipe for target '/home/sfr/next/perf/gtk-in.o' failed

(/home/sfr/next/perf/ is the object directory)
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Jiri,

On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa  wrote:
>
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap

OK, for now I will clean out my objdir before doing the perf build
after the tip tree merge.  It would be nice to have this fixed, though,
if possible.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Arnaldo Carvalho de Melo]

Em Wed, Sep 16, 2015 at 05:30:25PM +1000, Stephen Rothwell escreveu:
> Hi Jiri,
> 
> On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa  wrote:
> >
> > > > Also, building perf seems to ignore O= on the make invocation.
> > > > Is that expected?
> > > 
> > > hum, not sure about this one.. I'm not using it, but we have
> > > tests for this and I thought we're ok.. I'll check
> > 
> > seems to work on latest Arnaldo's perf/core,
> > what command line failed for you?
> > 
> > [jolsa@krava perf]$ make O=/tmp/krava/
> > ...
> > [jolsa@krava perf]$ ll /tmp/krava/perf
> > -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf
> 
> Thanks for the hint.  I was using a relative path and starting in the
> top of the kernel tree, so:

> $ cd kernel
> $ mkdir ../perf
> $ make -s -C tools/perf JOBS=24 O=../perf
> 
> put everything in toos/perf (no suprise really)
> 
> I will change my script to use an absolute path (which I checked does
> work fine).  Sorry for the noise.

Nice workaround, but I guess relative paths should be supported as well,
right? :)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Jiri,

On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa  wrote:
>
> > > Also, building perf seems to ignore O= on the make invocation.
> > > Is that expected?
> > 
> > hum, not sure about this one.. I'm not using it, but we have
> > tests for this and I thought we're ok.. I'll check
> 
> seems to work on latest Arnaldo's perf/core,
> what command line failed for you?
> 
> [jolsa@krava perf]$ make O=/tmp/krava/
> ...
> [jolsa@krava perf]$ ll /tmp/krava/perf
> -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf

Thanks for the hint.  I was using a relative path and starting in the
top of the kernel tree, so:

$ cd kernel
$ mkdir ../perf
$ make -s -C tools/perf JOBS=24 O=../perf

put everything in toos/perf (no suprise really)

I will change my script to use an absolute path (which I checked does
work fine).  Sorry for the noise.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jiri Olsa]

On Wed, Sep 16, 2015 at 08:16:52AM +0200, Jiri Olsa wrote:
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap
> 
> > 
> > I have used the tip tree from next-20150915 for today.
> > 
> > Also, building perf seems to ignore O= on the make invocation.
> > Is that expected?
> 
> hum, not sure about this one.. I'm not using it, but we have
> tests for this and I thought we're ok.. I'll check

seems to work on latest Arnaldo's perf/core,
what command line failed for you?

[jolsa@krava perf]$ make O=/tmp/krava/
...
[jolsa@krava perf]$ ll /tmp/krava/perf
-rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf


jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jiri Olsa]

On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (perf) failed
> like this:
> 
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> 'tools/perf/arch/common.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'arch' failed
> make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> 'tools/perf/fs/fs.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'fs' failed
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> 'tools/perf/util/abspath.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'util' failed
> Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> Makefile:68: recipe for target 'all' failed
> 
> Maybe caused by commit
> 
>   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> objects")
> 
> This is an incremental build i.e. I do not do a "make clean" after doing
> the build for each tree merge (in case that matters).

it does in this case, removed header files stay in
cmd build dependency file (like in .abspath.o.cmd above)
and cause build error

build system is not smart enough yet to find out,
I was postponning fixing this for some time now,
I'll try to get this resolved asap

> 
> I have used the tip tree from next-20150915 for today.
> 
> Also, building perf seems to ignore O= on the make invocation.
> Is that expected?

hum, not sure about this one.. I'm not using it, but we have
tests for this and I thought we're ok.. I'll check

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jiri Olsa]

On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (perf) failed
> like this:
> 
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> 'tools/perf/arch/common.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'arch' failed
> make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> 'tools/perf/fs/fs.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'fs' failed
> make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> 'tools/perf/util/abspath.o'.  Stop.
> tools/build/Makefile.build:109: recipe for target 'util' failed
> Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> Makefile:68: recipe for target 'all' failed
> 
> Maybe caused by commit
> 
>   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> objects")
> 
> This is an incremental build i.e. I do not do a "make clean" after doing
> the build for each tree merge (in case that matters).

it does in this case, removed header files stay in
cmd build dependency file (like in .abspath.o.cmd above)
and cause build error

build system is not smart enough yet to find out,
I was postponning fixing this for some time now,
I'll try to get this resolved asap

> 
> I have used the tip tree from next-20150915 for today.
> 
> Also, building perf seems to ignore O= on the make invocation.
> Is that expected?

hum, not sure about this one.. I'm not using it, but we have
tests for this and I thought we're ok.. I'll check

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jiri Olsa]

On Wed, Sep 16, 2015 at 08:16:52AM +0200, Jiri Olsa wrote:
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap
> 
> > 
> > I have used the tip tree from next-20150915 for today.
> > 
> > Also, building perf seems to ignore O= on the make invocation.
> > Is that expected?
> 
> hum, not sure about this one.. I'm not using it, but we have
> tests for this and I thought we're ok.. I'll check

seems to work on latest Arnaldo's perf/core,
what command line failed for you?

[jolsa@krava perf]$ make O=/tmp/krava/
...
[jolsa@krava perf]$ ll /tmp/krava/perf
-rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf


jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Jiri,

On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa  wrote:
>
> > > Also, building perf seems to ignore O= on the make invocation.
> > > Is that expected?
> > 
> > hum, not sure about this one.. I'm not using it, but we have
> > tests for this and I thought we're ok.. I'll check
> 
> seems to work on latest Arnaldo's perf/core,
> what command line failed for you?
> 
> [jolsa@krava perf]$ make O=/tmp/krava/
> ...
> [jolsa@krava perf]$ ll /tmp/krava/perf
> -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf

Thanks for the hint.  I was using a relative path and starting in the
top of the kernel tree, so:

$ cd kernel
$ mkdir ../perf
$ make -s -C tools/perf JOBS=24 O=../perf

put everything in toos/perf (no suprise really)

I will change my script to use an absolute path (which I checked does
work fine).  Sorry for the noise.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Arnaldo Carvalho de Melo]

Em Wed, Sep 16, 2015 at 05:30:25PM +1000, Stephen Rothwell escreveu:
> Hi Jiri,
> 
> On Wed, 16 Sep 2015 08:38:17 +0200 Jiri Olsa  wrote:
> >
> > > > Also, building perf seems to ignore O= on the make invocation.
> > > > Is that expected?
> > > 
> > > hum, not sure about this one.. I'm not using it, but we have
> > > tests for this and I thought we're ok.. I'll check
> > 
> > seems to work on latest Arnaldo's perf/core,
> > what command line failed for you?
> > 
> > [jolsa@krava perf]$ make O=/tmp/krava/
> > ...
> > [jolsa@krava perf]$ ll /tmp/krava/perf
> > -rwxrwxr-x. 1 jolsa jolsa 12669704 Sep 16 08:36 /tmp/krava/perf
> 
> Thanks for the hint.  I was using a relative path and starting in the
> top of the kernel tree, so:

> $ cd kernel
> $ mkdir ../perf
> $ make -s -C tools/perf JOBS=24 O=../perf
> 
> put everything in toos/perf (no suprise really)
> 
> I will change my script to use an absolute path (which I checked does
> work fine).  Sorry for the noise.

Nice workaround, but I guess relative paths should be supported as well,
right? :)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Jiri,

On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa  wrote:
>
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> > 
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> > 
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/arch/common.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
> > 'tools/perf/fs/fs.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
> > 'tools/perf/util/abspath.o'.  Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> > 
> > Maybe caused by commit
> > 
> >   60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs 
> > objects")
> > 
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
> 
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
> 
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap

OK, for now I will clean out my objdir before doing the perf build
after the tip tree merge.  It would be nice to have this fixed, though,
if possible.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Wed, 16 Sep 2015 11:30:53 +1000

> I have added the following fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Wed, 16 Sep 2015 11:10:16 +1000
> Subject: [PATCH] cdc: add header guards
> 
> Signed-off-by: Stephen Rothwell 

Applied, thanks Stephen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct 
usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:44:5: error: conflicting types for 
'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:44:5: note: previous declaration of 
'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct 
usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:44:5: error: conflicting types for 
'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:44:5: note: previous declaration of 
'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^

Caused by commit

  c40a2c8817e4 ("CDC: common parser for extra headers")

from the net-next tree that added include/linux/usb/cdc.h with no
reinclusion guards.

I am not sure why I did not see this failure when building after
merging the net-next tree.  Maybe it is exposed by some config change
in the tip tree?

I have added the following fix patch for today:

From: Stephen Rothwell 
Date: Wed, 16 Sep 2015 11:10:16 +1000
Subject: [PATCH] cdc: add header guards

Signed-off-by: Stephen Rothwell 
---
 include/linux/usb/cdc.h  | 4 
 include/uapi/linux/usb/cdc.h | 6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/cdc.h b/include/linux/usb/cdc.h
index 959d0c838113..b5706f94ee9e 100644
--- a/include/linux/usb/cdc.h
+++ b/include/linux/usb/cdc.h
@@ -7,6 +7,8 @@
  * modify it under the terms of the GNU General Public License
  * version 2 as published by the Free Software Foundation.
  */
+#ifndef __LINUX_USB_CDC_H
+#define __LINUX_USB_CDC_H
 
 #include 
 
@@ -45,3 +47,5 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
struct usb_interface *intf,
u8 *buffer,
int buflen);
+
+#endif /* __LINUX_USB_CDC_H */
diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h
index b6a9cdd6e096..e2bc417b243b 100644
--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -6,8 +6,8 @@
  * firmware based USB peripherals.
  */
 
-#ifndef __LINUX_USB_CDC_H
-#define __LINUX_USB_CDC_H
+#ifndef __UAPI_LINUX_USB_CDC_H
+#define __UAPI_LINUX_USB_CDC_H
 
 #include 
 
@@ -444,4 +444,4 @@ struct usb_cdc_ncm_ndp_input_size {
 #define USB_CDC_NCM_CRC_NOT_APPENDED   0x00
 #define USB_CDC_NCM_CRC_APPENDED   0x01
 
-#endif /* __LINUX_USB_CDC_H */
+#endif /* __UAPI_LINUX_USB_CDC_H */
-- 
2.5.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (perf) failed
like this:

make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
'tools/perf/arch/common.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'arch' failed
make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
'tools/perf/fs/fs.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'fs' failed
make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
'tools/perf/util/abspath.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'util' failed
Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
Makefile:68: recipe for target 'all' failed

Maybe caused by commit

  60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")

This is an incremental build i.e. I do not do a "make clean" after doing
the build for each tree merge (in case that matters).

I have used the tip tree from next-20150915 for today.

Also, building perf seems to ignore O= on the make invocation.
Is that expected?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Wed, 16 Sep 2015 11:30:53 +1000

> I have added the following fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Wed, 16 Sep 2015 11:10:16 +1000
> Subject: [PATCH] cdc: add header guards
> 
> Signed-off-by: Stephen Rothwell 

Applied, thanks Stephen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (perf) failed
like this:

make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
'tools/perf/arch/common.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'arch' failed
make[4]: *** No rule to make target 'fs/debugfs.h', needed by 
'tools/perf/fs/fs.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'fs' failed
make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by 
'tools/perf/util/abspath.o'.  Stop.
tools/build/Makefile.build:109: recipe for target 'util' failed
Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
Makefile:68: recipe for target 'all' failed

Maybe caused by commit

  60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs objects")

This is an incremental build i.e. I do not do a "make clean" after doing
the build for each tree merge (in case that matters).

I have used the tip tree from next-20150915 for today.

Also, building perf seems to ignore O= on the make invocation.
Is that expected?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct 
usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/function/f_ncm.c:26:
include/linux/usb/cdc.h:44:5: error: conflicting types for 
'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/f_ncm.c:24:0:
include/linux/usb/cdc.h:44:5: note: previous declaration of 
'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:23:8: error: redefinition of 'struct 
usb_cdc_parsed_header'
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:23:8: note: originally defined here
 struct usb_cdc_parsed_header {
^
In file included from drivers/usb/gadget/function/u_serial.h:16:0,
 from drivers/usb/gadget/legacy/cdc2.c:17:
include/linux/usb/cdc.h:44:5: error: conflicting types for 
'cdc_parse_cdc_header'
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^
In file included from drivers/usb/gadget/function/u_ether.h:20:0,
 from drivers/usb/gadget/legacy/cdc2.c:16:
include/linux/usb/cdc.h:44:5: note: previous declaration of 
'cdc_parse_cdc_header' was here
 int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
 ^

Caused by commit

  c40a2c8817e4 ("CDC: common parser for extra headers")

from the net-next tree that added include/linux/usb/cdc.h with no
reinclusion guards.

I am not sure why I did not see this failure when building after
merging the net-next tree.  Maybe it is exposed by some config change
in the tip tree?

I have added the following fix patch for today:

From: Stephen Rothwell 
Date: Wed, 16 Sep 2015 11:10:16 +1000
Subject: [PATCH] cdc: add header guards

Signed-off-by: Stephen Rothwell 
---
 include/linux/usb/cdc.h  | 4 
 include/uapi/linux/usb/cdc.h | 6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/usb/cdc.h b/include/linux/usb/cdc.h
index 959d0c838113..b5706f94ee9e 100644
--- a/include/linux/usb/cdc.h
+++ b/include/linux/usb/cdc.h
@@ -7,6 +7,8 @@
  * modify it under the terms of the GNU General Public License
  * version 2 as published by the Free Software Foundation.
  */
+#ifndef __LINUX_USB_CDC_H
+#define __LINUX_USB_CDC_H
 
 #include 
 
@@ -45,3 +47,5 @@ int cdc_parse_cdc_header(struct usb_cdc_parsed_header *hdr,
struct usb_interface *intf,
u8 *buffer,
int buflen);
+
+#endif /* __LINUX_USB_CDC_H */
diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h
index b6a9cdd6e096..e2bc417b243b 100644
--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -6,8 +6,8 @@
  * firmware based USB peripherals.
  */
 
-#ifndef __LINUX_USB_CDC_H
-#define __LINUX_USB_CDC_H
+#ifndef __UAPI_LINUX_USB_CDC_H
+#define __UAPI_LINUX_USB_CDC_H
 
 #include 
 
@@ -444,4 +444,4 @@ struct usb_cdc_ncm_ndp_input_size {
 #define USB_CDC_NCM_CRC_NOT_APPENDED   0x00
 #define USB_CDC_NCM_CRC_APPENDED   0x01
 
-#endif /* __LINUX_USB_CDC_H */
+#endif /* __UAPI_LINUX_USB_CDC_H */
-- 
2.5.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Luis R. Rodriguez]

On Tue, Jul 28, 2015 at 06:34:19PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
> > drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of 
> > function 'ioremap_uc' [-Werror=implicit-function-declaration]
> >   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
> >   ^
> > drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes 
> > pointer from integer without a cast
> >   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
> >^
> > 
> > Caused by commits
> > 
> >   3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with 
> > strong UC")
> >   8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant 
> > default")
> > 
> > The latter defines ioremap_uc() for x86 and those architectures that
> > use asm-generic/io.h - which is not all of them :-( .  The former commit
> > then uses ioremap_uc().
> > 
> > I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
> > for today.
> 
> This should be fixed by:
> 
> http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb
> 
> The way it was defined was to return NULL if an arch does not have it,
> *but* if the asm-generic io.h header is not included on some archs it will 
> still
> fail, which leaves us no option but to then poke and define its implementaiton
> for archs which opt-out of asm-generic io.h
> 
> Benh, in this case I believe its OK to to just map it to ioremap(), let me 
> know
> what you think.
> 

I checked and there are other architectures that do not include 
asm-generic/io.h,
so here is the full patch fix, which I'll post next.

From: "Luis R. Rodriguez" 
Subject: [PATCH] arch/*/io.h: Add ioremap_uc() to all architectures

This adds ioremap_uc() only for architectures that do not
include asm-generic.h/io.h as that already provides a default
definition for them for both cases where you have CONFIG_MMU
and you do not, and because of this, the number of architectures
this patch address is less than the architectures that the
ioremap_wt() patch addressed, "arch/*/io.h: Add ioremap_wt() to all
architectures").

In order to reduce the number of architectures we have to
modify by adding new architecture IO APIs we'll have to review
the architectures in this patch, see why they can't add
asm-generic.h/io.h or issues that would be created by doing
so and then spread a consistent inclusion of this header
towards the end of their own header. For instance arch/metag
includes the asm-generic/io.h *before* the ioremap*()
definitions, this should be the other way around but only
once we have guard wrappers for the non-MMU case also for
asm-generic/io.h.

Signed-off-by: Luis R. Rodriguez 
---
 arch/avr32/include/asm/io.h   | 1 +
 arch/frv/include/asm/io.h | 1 +
 arch/m32r/include/asm/io.h| 1 +
 arch/m68k/include/asm/io_mm.h | 1 +
 arch/mn10300/include/asm/io.h | 1 +
 arch/powerpc/include/asm/io.h | 1 +
 arch/sh/include/asm/io.h  | 1 +
 arch/tile/include/asm/io.h| 1 +
 8 files changed, 8 insertions(+)

diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index e998ff5d8e1a..f855646e0db7 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -297,6 +297,7 @@ extern void __iounmap(void __iomem *addr);
 
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 #define cached(addr) P1SEGADDR(addr)
 #define uncached(addr) P2SEGADDR(addr)
diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index a31b63ec4930..70dfbea8c8d7 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -278,6 +278,7 @@ static inline void __iomem *ioremap_fullcache(unsigned long 
physaddr, unsigned l
 }
 
 #define ioremap_wc ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 extern void iounmap(void volatile __iomem *addr);
 
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index f8de767ce2bc..61b8931bc192 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -69,6 +69,7 @@ extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(off,size) ioremap(off,size)
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 /*
  * IO bus memory addresses are also 1:1 with the physical address
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index f55cad529400..c98ac81582ac 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -468,6 +468,7 @@ static inline void __iomem *ioremap_nocache(unsigned long 
physaddr, unsigned lon
 {
return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
 }
+#define ioremap_uc 

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

[Luis R. Rodriguez]

On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
> drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of 
> function 'ioremap_uc' [-Werror=implicit-function-declaration]
>   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>   ^
> drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes 
> pointer from integer without a cast
>   par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>^
> 
> Caused by commits
> 
>   3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong 
> UC")
>   8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")
> 
> The latter defines ioremap_uc() for x86 and those architectures that
> use asm-generic/io.h - which is not all of them :-( .  The former commit
> then uses ioremap_uc().
> 
> I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
> for today.

This should be fixed by:

http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb

The way it was defined was to return NULL if an arch does not have it,
*but* if the asm-generic io.h header is not included on some archs it will still
fail, which leaves us no option but to then poke and define its implementaiton
for archs which opt-out of asm-generic io.h

Benh, in this case I believe its OK to to just map it to ioremap(), let me know
what you think.

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a8d2ef30d473..91db9153cd44 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, 
unsigned long size,
  unsigned long flags);
 extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
 #define ioremap_nocache(addr, size)ioremap((addr), (size))
+#define ioremap_uc(addr, size) ioremap((addr), (size))
 
 extern void iounmap(volatile void __iomem *addr);
 

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gregory CLEMENT]

Hi Sudeep, Stephen,

On 28/07/2015 10:41, Sudeep Holla wrote:
> Hi Stephen,
> 
> On 28/07/15 03:43, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
>> arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of 
>> function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
>> gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
>> ^
>>
>> Caused by commit
>>
>>e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby 
>> mode")
>>
>> from the mvebu tree interacting with commit
>>
>>0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")
>>
>> from the tip tree.
>>
>> I have applied the following merge fix patch for today:
>>
> 
> Thanks for the fix, I was aware of this and asked Thomas Petazzoni
> and Gregory CLEMENT to revert the commit e6f134f8e30e if possible
> yesterday [1]
> 

I've just remove the commit from my branches, it should be OK now.


Thanks,

Gregory


> Regards,
> Sudeep
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sudeep Holla]

Hi Stephen,

On 28/07/15 03:43, Stephen Rothwell wrote:

Hi all,

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

arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 
'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
^

Caused by commit

   e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")

from the mvebu tree interacting with commit

   0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")

from the tip tree.

I have applied the following merge fix patch for today:



Thanks for the fix, I was aware of this and asked Thomas Petazzoni
and Gregory CLEMENT to revert the commit e6f134f8e30e if possible
yesterday [1]

Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Sudeep Holla]

Hi Stephen,

On 28/07/15 03:43, Stephen Rothwell wrote:

Hi all,

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

arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 
'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
^

Caused by commit

   e6f134f8e30e (ARM: mvebu: Allow using the GIC for wakeup in standby mode)

from the mvebu tree interacting with commit

   0d3f2c92e004 (irqchip/gic: Remove redundant gic_set_irqchip_flags)

from the tip tree.

I have applied the following merge fix patch for today:



Thanks for the fix, I was aware of this and asked Thomas Petazzoni
and Gregory CLEMENT to revert the commit e6f134f8e30e if possible
yesterday [1]

Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gregory CLEMENT]

Hi Sudeep, Stephen,

On 28/07/2015 10:41, Sudeep Holla wrote:
 Hi Stephen,
 
 On 28/07/15 03:43, Stephen Rothwell wrote:
 Hi all,

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

 arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
 arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of 
 function 'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
 gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
 ^

 Caused by commit

e6f134f8e30e (ARM: mvebu: Allow using the GIC for wakeup in standby 
 mode)

 from the mvebu tree interacting with commit

0d3f2c92e004 (irqchip/gic: Remove redundant gic_set_irqchip_flags)

 from the tip tree.

 I have applied the following merge fix patch for today:

 
 Thanks for the fix, I was aware of this and asked Thomas Petazzoni
 and Gregory CLEMENT to revert the commit e6f134f8e30e if possible
 yesterday [1]
 

I've just remove the commit from my branches, it should be OK now.


Thanks,

Gregory


 Regards,
 Sudeep
 
 [1] 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359585.html
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Luis R. Rodriguez]

On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
 Hi all,
 
 After merging the tip tree, today's linux-next build (powerpc
 allyesconfig) failed like this:
 
 drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
 drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of 
 function 'ioremap_uc' [-Werror=implicit-function-declaration]
   par-ati_regbase = ioremap_uc(info-fix.mmio_start, 0x1000);
   ^
 drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes 
 pointer from integer without a cast
   par-ati_regbase = ioremap_uc(info-fix.mmio_start, 0x1000);
^
 
 Caused by commits
 
   3cc2dac5be3f (drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong 
 UC)
   8c7ea50c010b (x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default)
 
 The latter defines ioremap_uc() for x86 and those architectures that
 use asm-generic/io.h - which is not all of them :-( .  The former commit
 then uses ioremap_uc().
 
 I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
 for today.

This should be fixed by:

http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb

The way it was defined was to return NULL if an arch does not have it,
*but* if the asm-generic io.h header is not included on some archs it will still
fail, which leaves us no option but to then poke and define its implementaiton
for archs which opt-out of asm-generic io.h

Benh, in this case I believe its OK to to just map it to ioremap(), let me know
what you think.

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a8d2ef30d473..91db9153cd44 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -721,6 +721,7 @@ extern void __iomem *ioremap_prot(phys_addr_t address, 
unsigned long size,
  unsigned long flags);
 extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
 #define ioremap_nocache(addr, size)ioremap((addr), (size))
+#define ioremap_uc(addr, size) ioremap((addr), (size))
 
 extern void iounmap(volatile void __iomem *addr);
 

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Luis R. Rodriguez]

On Tue, Jul 28, 2015 at 06:34:19PM +0200, Luis R. Rodriguez wrote:
 On Tue, Jul 28, 2015 at 03:33:03PM +1000, Stephen Rothwell wrote:
  Hi all,
  
  After merging the tip tree, today's linux-next build (powerpc
  allyesconfig) failed like this:
  
  drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
  drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of 
  function 'ioremap_uc' [-Werror=implicit-function-declaration]
par-ati_regbase = ioremap_uc(info-fix.mmio_start, 0x1000);
^
  drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes 
  pointer from integer without a cast
par-ati_regbase = ioremap_uc(info-fix.mmio_start, 0x1000);
 ^
  
  Caused by commits
  
3cc2dac5be3f (drivers/video/fbdev/atyfb: Replace MTRR UC hole with 
  strong UC)
8c7ea50c010b (x86/mm, asm-generic: Add IOMMU ioremap_uc() variant 
  default)
  
  The latter defines ioremap_uc() for x86 and those architectures that
  use asm-generic/io.h - which is not all of them :-( .  The former commit
  then uses ioremap_uc().
  
  I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
  for today.
 
 This should be fixed by:
 
 http://git.kernel.org/tip/8c7ea50c010b2f1e006ad37c43f98202a31de2cb
 
 The way it was defined was to return NULL if an arch does not have it,
 *but* if the asm-generic io.h header is not included on some archs it will 
 still
 fail, which leaves us no option but to then poke and define its implementaiton
 for archs which opt-out of asm-generic io.h
 
 Benh, in this case I believe its OK to to just map it to ioremap(), let me 
 know
 what you think.
 

I checked and there are other architectures that do not include 
asm-generic/io.h,
so here is the full patch fix, which I'll post next.

From: Luis R. Rodriguez mcg...@suse.com
Subject: [PATCH] arch/*/io.h: Add ioremap_uc() to all architectures

This adds ioremap_uc() only for architectures that do not
include asm-generic.h/io.h as that already provides a default
definition for them for both cases where you have CONFIG_MMU
and you do not, and because of this, the number of architectures
this patch address is less than the architectures that the
ioremap_wt() patch addressed, arch/*/io.h: Add ioremap_wt() to all
architectures).

In order to reduce the number of architectures we have to
modify by adding new architecture IO APIs we'll have to review
the architectures in this patch, see why they can't add
asm-generic.h/io.h or issues that would be created by doing
so and then spread a consistent inclusion of this header
towards the end of their own header. For instance arch/metag
includes the asm-generic/io.h *before* the ioremap*()
definitions, this should be the other way around but only
once we have guard wrappers for the non-MMU case also for
asm-generic/io.h.

Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 arch/avr32/include/asm/io.h   | 1 +
 arch/frv/include/asm/io.h | 1 +
 arch/m32r/include/asm/io.h| 1 +
 arch/m68k/include/asm/io_mm.h | 1 +
 arch/mn10300/include/asm/io.h | 1 +
 arch/powerpc/include/asm/io.h | 1 +
 arch/sh/include/asm/io.h  | 1 +
 arch/tile/include/asm/io.h| 1 +
 8 files changed, 8 insertions(+)

diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index e998ff5d8e1a..f855646e0db7 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -297,6 +297,7 @@ extern void __iounmap(void __iomem *addr);
 
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 #define cached(addr) P1SEGADDR(addr)
 #define uncached(addr) P2SEGADDR(addr)
diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index a31b63ec4930..70dfbea8c8d7 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -278,6 +278,7 @@ static inline void __iomem *ioremap_fullcache(unsigned long 
physaddr, unsigned l
 }
 
 #define ioremap_wc ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 extern void iounmap(void volatile __iomem *addr);
 
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index f8de767ce2bc..61b8931bc192 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -69,6 +69,7 @@ extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(off,size) ioremap(off,size)
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
+#define ioremap_uc ioremap_nocache
 
 /*
  * IO bus memory addresses are also 1:1 with the physical address
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index f55cad529400..c98ac81582ac 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -468,6 +468,7 @@ static inline void __iomem *ioremap_nocache(unsigned long 
physaddr, unsigned lon
 {
return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
 }
+#define ioremap_uc ioremap_nocache
 static inline void __iomem *ioremap_wt(unsigned 

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

[Stephen Rothwell]

Hi all,

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

drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of 
function 'ioremap_uc' [-Werror=implicit-function-declaration]
  par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
  ^
drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer 
from integer without a cast
  par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
   ^

Caused by commits

  3cc2dac5be3f ("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong 
UC")
  8c7ea50c010b ("x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default")

The latter defines ioremap_uc() for x86 and those architectures that
use asm-generic/io.h - which is not all of them :-( .  The former commit
then uses ioremap_uc().

I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 
'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
   gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
   ^

Caused by commit

  e6f134f8e30e ("ARM: mvebu: Allow using the GIC for wakeup in standby mode")

from the mvebu tree interacting with commit

  0d3f2c92e004 ("irqchip/gic: Remove redundant gic_set_irqchip_flags")

from the tip tree.

I have applied the following merge fix patch for today:

From: Stephen Rothwell 
Date: Tue, 28 Jul 2015 12:26:21 +1000
Subject: [PATCH] irqchip/gic: merge fix for "Remove redundant 
gic_set_irqchip_flags"

Signed-off-by: Stephen Rothwell 
---
 arch/arm/mach-mvebu/board-v7.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index a6d2b4d6701a..b5ef80f369e7 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -131,13 +131,6 @@ static int armada_375_external_abort_wa(unsigned long 
addr, unsigned int fsr,
 
 static void __init mvebu_init_irq(void)
 {
-   struct device_node *np;
-
-   np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-gic");
-   if (np)
-   gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
- IRQCHIP_MASK_ON_SUSPEND);
-   of_node_put(np);
irqchip_init();
mvebu_scu_enable();
coherency_init();
-- 
2.4.6

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

drivers/video/fbdev/aty/atyfb_base.c: In function 'atyfb_setup_generic':
drivers/video/fbdev/aty/atyfb_base.c:3447:2: error: implicit declaration of 
function 'ioremap_uc' [-Werror=implicit-function-declaration]
  par-ati_regbase = ioremap_uc(info-fix.mmio_start, 0x1000);
  ^
drivers/video/fbdev/aty/atyfb_base.c:3447:19: warning: assignment makes pointer 
from integer without a cast
  par-ati_regbase = ioremap_uc(info-fix.mmio_start, 0x1000);
   ^

Caused by commits

  3cc2dac5be3f (drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong 
UC)
  8c7ea50c010b (x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default)

The latter defines ioremap_uc() for x86 and those architectures that
use asm-generic/io.h - which is not all of them :-( .  The former commit
then uses ioremap_uc().

I have reverted commit 3cc2dac5be3f (and 7d89a3cb159a that follows it)
for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

arch/arm/mach-mvebu/board-v7.c: In function 'mvebu_init_irq':
arch/arm/mach-mvebu/board-v7.c:138:3: error: implicit declaration of function 
'gic_set_irqchip_flags' [-Werror=implicit-function-declaration]
   gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
   ^

Caused by commit

  e6f134f8e30e (ARM: mvebu: Allow using the GIC for wakeup in standby mode)

from the mvebu tree interacting with commit

  0d3f2c92e004 (irqchip/gic: Remove redundant gic_set_irqchip_flags)

from the tip tree.

I have applied the following merge fix patch for today:

From: Stephen Rothwell s...@canb.auug.org.au
Date: Tue, 28 Jul 2015 12:26:21 +1000
Subject: [PATCH] irqchip/gic: merge fix for Remove redundant 
gic_set_irqchip_flags

Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
 arch/arm/mach-mvebu/board-v7.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index a6d2b4d6701a..b5ef80f369e7 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -131,13 +131,6 @@ static int armada_375_external_abort_wa(unsigned long 
addr, unsigned int fsr,
 
 static void __init mvebu_init_irq(void)
 {
-   struct device_node *np;
-
-   np = of_find_compatible_node(NULL, NULL, arm,cortex-a9-gic);
-   if (np)
-   gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE |
- IRQCHIP_MASK_ON_SUSPEND);
-   of_node_put(np);
irqchip_init();
mvebu_scu_enable();
coherency_init();
-- 
2.4.6

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

drivers/pinctrl/sirf/pinctrl-atlas7.c: In function 'atlas7_gpio_handle_irq':
drivers/pinctrl/sirf/pinctrl-atlas7.c:4300:20: error: 'irq' undeclared (first 
use in this function)
   if (bank->irq == irq)
^

Caused by commit

  5dc1aeb0340f ("pinctrl/sirf: 
Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch")
[hmmm, not a wonderful commit summary line]

I tried to use the tip tree from next-20150714, but for some reason that
broke the perf build:

  BUILD:   Doing 'make -j48' parallel build
make[3]: *** No rule to make target '../lib/hweight.c', needed by 
'/scratch/sfr/next/tools/perf/util/hweight.o'.  Stop.

So instead, I applied the following fix patch for today's issue:

From: Stephen Rothwell 
Date: Wed, 15 Jul 2015 10:56:28 +1000
Subject: [PATCH] pinctrl/sirf: fix for 
Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch

Signed-off-by: Stephen Rothwell 
---
 drivers/pinctrl/sirf/pinctrl-atlas7.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c 
b/drivers/pinctrl/sirf/pinctrl-atlas7.c
index f55c931f1088..7917b7719939 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas7.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c
@@ -4294,6 +4294,7 @@ static void atlas7_gpio_handle_irq(unsigned int __irq, 
struct irq_desc *desc)
u32 status, ctrl;
int pin_in_bank = 0, idx;
struct irq_chip *chip = irq_desc_get_chip(desc);
+   unsigned int irq = irq_desc_get_irq(desc);
 
for (idx = 0; idx < a7gc->nbank; idx++) {
bank = >banks[idx];
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

drivers/pinctrl/sirf/pinctrl-atlas7.c: In function 'atlas7_gpio_handle_irq':
drivers/pinctrl/sirf/pinctrl-atlas7.c:4300:20: error: 'irq' undeclared (first 
use in this function)
   if (bank-irq == irq)
^

Caused by commit

  5dc1aeb0340f (pinctrl/sirf: 
Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch)
[hmmm, not a wonderful commit summary line]

I tried to use the tip tree from next-20150714, but for some reason that
broke the perf build:

  BUILD:   Doing 'make -j48' parallel build
make[3]: *** No rule to make target '../lib/hweight.c', needed by 
'/scratch/sfr/next/tools/perf/util/hweight.o'.  Stop.

So instead, I applied the following fix patch for today's issue:

From: Stephen Rothwell s...@canb.auug.org.au
Date: Wed, 15 Jul 2015 10:56:28 +1000
Subject: [PATCH] pinctrl/sirf: fix for 
Prepare-x-gpio-handle-irq-for-irq-argument-removal.patch

Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
 drivers/pinctrl/sirf/pinctrl-atlas7.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c 
b/drivers/pinctrl/sirf/pinctrl-atlas7.c
index f55c931f1088..7917b7719939 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas7.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c
@@ -4294,6 +4294,7 @@ static void atlas7_gpio_handle_irq(unsigned int __irq, 
struct irq_desc *desc)
u32 status, ctrl;
int pin_in_bank = 0, idx;
struct irq_chip *chip = irq_desc_get_chip(desc);
+   unsigned int irq = irq_desc_get_irq(desc);
 
for (idx = 0; idx  a7gc-nbank; idx++) {
bank = a7gc-banks[idx];
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Thomas Gleixner]

On Wed, 8 Jul 2015, Stephen Rothwell wrote:
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> kernel/cpu.c: In function '_cpu_down':
> kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' 
> [-Werror=implicit-function-declaration]
>   irq_lock_sparse();
>   ^
> kernel/cpu.c:407:3: error: implicit declaration of function 
> 'irq_unlock_sparse' [-Werror=implicit-function-declaration]
>irq_unlock_sparse();
>^
> 
> Caused by commit
> 
>   fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu 
> up/down")
> 
> Forgot to include linux/irqdesc.h.
> 
> I have used the tip tree from next-20150707 for today.

Fixed in tip. Sorry for the hickup.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Thomas Gleixner]

On Wed, 8 Jul 2015, Stephen Rothwell wrote:
 After merging the tip tree, today's linux-next build (arm
 multi_v7_defconfig) failed like this:
 
 kernel/cpu.c: In function '_cpu_down':
 kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' 
 [-Werror=implicit-function-declaration]
   irq_lock_sparse();
   ^
 kernel/cpu.c:407:3: error: implicit declaration of function 
 'irq_unlock_sparse' [-Werror=implicit-function-declaration]
irq_unlock_sparse();
^
 
 Caused by commit
 
   fc862aa8288b (hotplug: Prevent alloc/free of irq descriptors during cpu 
 up/down)
 
 Forgot to include linux/irqdesc.h.
 
 I have used the tip tree from next-20150707 for today.

Fixed in tip. Sorry for the hickup.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

kernel/cpu.c: In function '_cpu_down':
kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' 
[-Werror=implicit-function-declaration]
  irq_lock_sparse();
  ^
kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse' 
[-Werror=implicit-function-declaration]
   irq_unlock_sparse();
   ^

Caused by commit

  fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu 
up/down")

Forgot to include linux/irqdesc.h.

I have used the tip tree from next-20150707 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpM29tfFp18n.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

kernel/cpu.c: In function '_cpu_down':
kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse' 
[-Werror=implicit-function-declaration]
  irq_lock_sparse();
  ^
kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse' 
[-Werror=implicit-function-declaration]
   irq_unlock_sparse();
   ^

Caused by commit

  fc862aa8288b (hotplug: Prevent alloc/free of irq descriptors during cpu 
up/down)

Forgot to include linux/irqdesc.h.

I have used the tip tree from next-20150707 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpM29tfFp18n.pgp
Description: OpenPGP digital signature

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

[Chickles, Derek]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
>  ...
> > Thanks. Much appreciated.
> 
> This doesn't work, neither of these emails are a formal proper submission
> of a fix for this build failure.
> 
> One of you has to do the work to formally submit the patch to netdev
> with a full signoff and commit log message so that it gets fixed in my
> tree.
> 
> Thanks.

Yes, we're working on this. Hopefully, we'll have this submitted later today, 
with the build fix and sparse warning fixes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: "Chickles, Derek" 
Date: Fri, 12 Jun 2015 15:59:54 +

>> -Original Message-
>> From: Michael Ellerman [mailto:m...@ellerman.id.au]
>> Sent: Friday, June 12, 2015 3:51 AM
>> To: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; David
>> S.Miller
>> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> s...@canb.auug.org.au; Chickles, Derek; Burla, Satananda; Manlunas, Felix;
>> Richter, Robert; Makarov, Aleksey; Vatsavayi, Raghu
>> Subject: linux-next: build failure after merge of the tip tree
>> 
>> Hi all,
>> 
>> After merging the tip tree, today's linux-next build (x86_allmodconfig)
>> failed like this:
 ...
>> And so on.
>> 
>> Caused by the interaction of commit d6472302f242 "x86/mm: Decouple
>>  from " from the tip tree with commit
>> f21fb3ed364b
>> "Add support of Cavium Liquidio ethernet adapters" from the net-next tree.
>> 
>> I applied the following fix for today:
 ...
> Thanks. Much appreciated.

This doesn't work, neither of these emails are a formal proper submission
of a fix for this build failure.

One of you has to do the work to formally submit the patch to netdev
with a full signoff and commit log message so that it gets fixed in my
tree.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michael Ellerman]

Hi all,

After merging the tip tree, today's linux-next build (x86_allmodconfig)
failed like this:

  drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 
'octeon_init_instr_queue':
  drivers/net/ethernet/cavium/liquidio/request_manager.c:111:2: error: implicit 
declaration of function 'vmalloc' [-Werror=implicit-function-declaration]
iq->request_list = vmalloc(sizeof(*iq->request_list) * num_descs);
^
  drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 
'octeon_delete_instr_queue':
  drivers/net/ethernet/cavium/liquidio/request_manager.c:178:3: error: implicit 
declaration of function 'vfree' [-Werror=implicit-function-declaration]
 vfree(iq->request_list);
 ^
  drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 
'octeon_free_device_mem':
  drivers/net/ethernet/cavium/liquidio/octeon_device.c:653:4: error: implicit 
declaration of function 'vfree' [-Werror=implicit-function-declaration]
  vfree(oct->droq[i]);
  ^

And so on.

Caused by the interaction of commit d6472302f242 "x86/mm: Decouple
 from " from the tip tree with commit f21fb3ed364b
"Add support of Cavium Liquidio ethernet adapters" from the net-next tree.

I applied the following fix for today:

diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c 
b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
index 2ca91657295f..4e581facae2c 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c 
b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
index 60a186f1609b..94b502a0cf33 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"
diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c 
b/drivers/net/ethernet/cavium/liquidio/request_manager.c
index adb428463495..cd58660dd161 100644
--- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "octeon_config.h"
 #include "liquidio_common.h"
 #include "octeon_droq.h"


cheers



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Chickles, Derek]

 -Original Message-
 From: David Miller [mailto:da...@davemloft.net]
  ...
  Thanks. Much appreciated.
 
 This doesn't work, neither of these emails are a formal proper submission
 of a fix for this build failure.
 
 One of you has to do the work to formally submit the patch to netdev
 with a full signoff and commit log message so that it gets fixed in my
 tree.
 
 Thanks.

Yes, we're working on this. Hopefully, we'll have this submitted later today, 
with the build fix and sparse warning fixes.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Chickles, Derek derek.chick...@caviumnetworks.com
Date: Fri, 12 Jun 2015 15:59:54 +

 -Original Message-
 From: Michael Ellerman [mailto:m...@ellerman.id.au]
 Sent: Friday, June 12, 2015 3:51 AM
 To: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Peter Zijlstra; David
 S.Miller
 Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org;
 s...@canb.auug.org.au; Chickles, Derek; Burla, Satananda; Manlunas, Felix;
 Richter, Robert; Makarov, Aleksey; Vatsavayi, Raghu
 Subject: linux-next: build failure after merge of the tip tree
 
 Hi all,
 
 After merging the tip tree, today's linux-next build (x86_allmodconfig)
 failed like this:
 ...
 And so on.
 
 Caused by the interaction of commit d6472302f242 x86/mm: Decouple
 linux/vmalloc.h from asm/io.h from the tip tree with commit
 f21fb3ed364b
 Add support of Cavium Liquidio ethernet adapters from the net-next tree.
 
 I applied the following fix for today:
 ...
 Thanks. Much appreciated.

This doesn't work, neither of these emails are a formal proper submission
of a fix for this build failure.

One of you has to do the work to formally submit the patch to netdev
with a full signoff and commit log message so that it gets fixed in my
tree.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Michael Ellerman]

Hi all,

After merging the tip tree, today's linux-next build (x86_allmodconfig)
failed like this:

  drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 
'octeon_init_instr_queue':
  drivers/net/ethernet/cavium/liquidio/request_manager.c:111:2: error: implicit 
declaration of function 'vmalloc' [-Werror=implicit-function-declaration]
iq-request_list = vmalloc(sizeof(*iq-request_list) * num_descs);
^
  drivers/net/ethernet/cavium/liquidio/request_manager.c: In function 
'octeon_delete_instr_queue':
  drivers/net/ethernet/cavium/liquidio/request_manager.c:178:3: error: implicit 
declaration of function 'vfree' [-Werror=implicit-function-declaration]
 vfree(iq-request_list);
 ^
  drivers/net/ethernet/cavium/liquidio/octeon_device.c: In function 
'octeon_free_device_mem':
  drivers/net/ethernet/cavium/liquidio/octeon_device.c:653:4: error: implicit 
declaration of function 'vfree' [-Werror=implicit-function-declaration]
  vfree(oct-droq[i]);
  ^

And so on.

Caused by the interaction of commit d6472302f242 x86/mm: Decouple
linux/vmalloc.h from asm/io.h from the tip tree with commit f21fb3ed364b
Add support of Cavium Liquidio ethernet adapters from the net-next tree.

I applied the following fix for today:

diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c 
b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
index 2ca91657295f..4e581facae2c 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
@@ -27,6 +27,7 @@
 #include linux/crc32.h
 #include linux/kthread.h
 #include linux/netdevice.h
+#include linux/vmalloc.h
 #include octeon_config.h
 #include liquidio_common.h
 #include octeon_droq.h
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c 
b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
index 60a186f1609b..94b502a0cf33 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_droq.c
@@ -25,6 +25,7 @@
 #include linux/pci.h
 #include linux/kthread.h
 #include linux/netdevice.h
+#include linux/vmalloc.h
 #include octeon_config.h
 #include liquidio_common.h
 #include octeon_droq.h
diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c 
b/drivers/net/ethernet/cavium/liquidio/request_manager.c
index adb428463495..cd58660dd161 100644
--- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
@@ -26,6 +26,7 @@
 #include linux/pci.h
 #include linux/kthread.h
 #include linux/netdevice.h
+#include linux/vmalloc.h
 #include octeon_config.h
 #include liquidio_common.h
 #include octeon_droq.h


cheers



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

In file included from include/linux/kernel.h:13:0,
 from include/linux/interrupt.h:5,
 from drivers/iommu/intel_irq_remapping.c:4:
drivers/iommu/intel_irq_remapping.c: In function 'intel_enable_irq_remapping':
drivers/iommu/intel_irq_remapping.c:656:48: error: 'eim' undeclared (first use 
in this function)
  pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
^

Caused by my mismerge :-(

I added this merge fix patch (and will fix the merge itself tomorrow):

From: Stephen Rothwell 
Date: Tue, 9 Jun 2015 17:12:00 +1000
Subject: [PATCH] iommu.vt-d: fix mismerge

Signed-off-by: Stephen Rothwell 
---
 drivers/iommu/intel_irq_remapping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 0d2500d17a2f..c19918471b3a 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -653,7 +653,7 @@ static int __init intel_enable_irq_remapping(void)
 
irq_remapping_enabled = 1;
 
-   pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
+   pr_info("Enabled IRQ remapping in %s mode\n", eim_mode ? "x2apic" : 
"xapic");
 
return eim_mode ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
 
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpYRt5XH_HGt.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

In file included from include/linux/kernel.h:13:0,
 from include/linux/interrupt.h:5,
 from drivers/iommu/intel_irq_remapping.c:4:
drivers/iommu/intel_irq_remapping.c: In function 'intel_enable_irq_remapping':
drivers/iommu/intel_irq_remapping.c:656:48: error: 'eim' undeclared (first use 
in this function)
  pr_info(Enabled IRQ remapping in %s mode\n, eim ? x2apic : xapic);
^

Caused by my mismerge :-(

I added this merge fix patch (and will fix the merge itself tomorrow):

From: Stephen Rothwell s...@canb.auug.org.au
Date: Tue, 9 Jun 2015 17:12:00 +1000
Subject: [PATCH] iommu.vt-d: fix mismerge

Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
 drivers/iommu/intel_irq_remapping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 0d2500d17a2f..c19918471b3a 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -653,7 +653,7 @@ static int __init intel_enable_irq_remapping(void)
 
irq_remapping_enabled = 1;
 
-   pr_info(Enabled IRQ remapping in %s mode\n, eim ? x2apic : xapic);
+   pr_info(Enabled IRQ remapping in %s mode\n, eim_mode ? x2apic : 
xapic);
 
return eim_mode ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
 
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpYRt5XH_HGt.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Wed, 8 Apr 2015 15:03:27 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann  
> wrote:
> >
> > On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> > > On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> > >> [ Cc'ing Dave, fyi ]
> > >>
> > >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> > >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
> > >>>  wrote:
> >  On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> > > * Stephen Rothwell  wrote:
> > >
> > >> After merging the tip tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) failed like this:
> > >>
> > >> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> > >> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
> > >> member named 'prog_type'
> > >> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > >>  ^
> > >>
> > >> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> > >> attached to kprobes").
> > >
> > > Note, this must be some (rarely triggered) aspect of the ppc64
> > > defconfig that neither x86 randconfigs nor most other arch defconfigs
> > > expose?
> > 
> >  Note, this is a merge conflict with the work that went via net-next
> >  tree,
> >  i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> >  bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> > 
> >  You should be able to resolve it in linux-next by changing the test to:
> > 
> >  if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
> > >>>
> > >>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
> > >>> to tell Linus.
> > >>
> > >> Yes, indeed, depending which tree is merged first.
> > >
> > > Daniel analysis is correct, but the fix for kernel/events/core.c
> > > should be:
> > > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > > + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> > > instead of 'prog->prog_type'
> > 
> > Yes, absolutely, thanks!
> 
> So I have applied that as a merge fix patch.

This patch is now needed when the net-next tree is merged with Linus'
tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp8FB_rqTH9Y.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Wed, 8 Apr 2015 15:03:27 +1000 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 Hi all,
 
 On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann dan...@iogearbox.net 
 wrote:
 
  On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
   On 4/7/15 4:13 AM, Daniel Borkmann wrote:
   [ Cc'ing Dave, fyi ]
  
   On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
   On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
   dan...@iogearbox.net wrote:
   On 04/07/2015 10:48 AM, Ingo Molnar wrote:
   * Stephen Rothwell s...@canb.auug.org.au wrote:
  
   After merging the tip tree, today's linux-next build (powerpc
   ppc64_defconfig) failed like this:
  
   kernel/events/core.c: In function 'perf_event_set_bpf_prog':
   kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
   member named 'prog_type'
   if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
^
  
   Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
   attached to kprobes).
  
   Note, this must be some (rarely triggered) aspect of the ppc64
   defconfig that neither x86 randconfigs nor most other arch defconfigs
   expose?
  
   Note, this is a merge conflict with the work that went via net-next
   tree,
   i.e. 24701ecea76b (ebpf: move read-only fields to bpf_prog and shrink
   bpf_prog_aux). I believe that is why it didn't trigger on tip tree.
  
   You should be able to resolve it in linux-next by changing the test to:
  
   if (prog-prog_type != BPF_PROG_TYPE_KPROBE) {
  
   Thanks Daniel, I will do that tomorrow.  Someone will have to remember
   to tell Linus.
  
   Yes, indeed, depending which tree is merged first.
  
   Daniel analysis is correct, but the fix for kernel/events/core.c
   should be:
   - if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
   + if (prog-type != BPF_PROG_TYPE_KPROBE) {
   instead of 'prog-prog_type'
  
  Yes, absolutely, thanks!
 
 So I have applied that as a merge fix patch.

This patch is now needed when the net-next tree is merged with Linus'
tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp8FB_rqTH9Y.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Russell,

On Mon, 30 Mar 2015 16:08:38 +0100 Russell King - ARM Linux 
 wrote:
>
> On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
> > On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> > > Hi Russell,
> > > 
> > > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
> > >  wrote:
> > >>
> > >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> > >> it in my tree and keep my tree buildable without dragging in the tip
> > >> tree.
> > > 
> > > Does it affect your tree on its own?  If not, then it can be fixed when
> > > merged as I have done, or if you look at the tip tree, all you really
> > > need to merge is tip timers/core branch (which I am sure the tip guys
> > > can tell you if it is stable enough) which is about 28 commits ...
> > > 
> > >> The ARM VDSO stuff will just have to wait for 4.2 instead.
> > > 
> > > If that works for you.
> > 
> > FWIW, Stephen's merge fix is correct and I have run my vdso tests
> > without problems on OMAP5 with next-20150330.
> 
> Hopefully, I can pull the tip stuff but if not, I'll try to remember
> to include Stephen's patch with my pull request, but I can't make any
> guarantees - Stephen's email will very quickly get buried in my mailbox,
> and I'll most likely forget about it too... I'm notoriously bad with
> email...

This patch is now needed when the arm tree is merged with Linus' tree
(the tip tree part has been merged).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpD5BbCR16h9.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Russell,

On Mon, 30 Mar 2015 16:08:38 +0100 Russell King - ARM Linux 
li...@arm.linux.org.uk wrote:

 On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
  On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
   Hi Russell,
   
   On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
   li...@arm.linux.org.uk wrote:
  
   I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
   it in my tree and keep my tree buildable without dragging in the tip
   tree.
   
   Does it affect your tree on its own?  If not, then it can be fixed when
   merged as I have done, or if you look at the tip tree, all you really
   need to merge is tip timers/core branch (which I am sure the tip guys
   can tell you if it is stable enough) which is about 28 commits ...
   
   The ARM VDSO stuff will just have to wait for 4.2 instead.
   
   If that works for you.
  
  FWIW, Stephen's merge fix is correct and I have run my vdso tests
  without problems on OMAP5 with next-20150330.
 
 Hopefully, I can pull the tip stuff but if not, I'll try to remember
 to include Stephen's patch with my pull request, but I can't make any
 guarantees - Stephen's email will very quickly get buried in my mailbox,
 and I'll most likely forget about it too... I'm notoriously bad with
 email...

This patch is now needed when the arm tree is merged with Linus' tree
(the tip tree part has been merged).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpD5BbCR16h9.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann  wrote:
>
> On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
> > On 4/7/15 4:13 AM, Daniel Borkmann wrote:
> >> [ Cc'ing Dave, fyi ]
> >>
> >> On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
> >>> On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
> >>>  wrote:
>  On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> > * Stephen Rothwell  wrote:
> >
> >> After merging the tip tree, today's linux-next build (powerpc
> >> ppc64_defconfig) failed like this:
> >>
> >> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> >> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
> >> member named 'prog_type'
> >> if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>  ^
> >>
> >> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> >> attached to kprobes").
> >
> > Note, this must be some (rarely triggered) aspect of the ppc64
> > defconfig that neither x86 randconfigs nor most other arch defconfigs
> > expose?
> 
>  Note, this is a merge conflict with the work that went via net-next
>  tree,
>  i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
>  bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> 
>  You should be able to resolve it in linux-next by changing the test to:
> 
>  if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {
> >>>
> >>> Thanks Daniel, I will do that tomorrow.  Someone will have to remember
> >>> to tell Linus.
> >>
> >> Yes, indeed, depending which tree is merged first.
> >
> > Daniel analysis is correct, but the fix for kernel/events/core.c
> > should be:
> > - if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> > + if (prog->type != BPF_PROG_TYPE_KPROBE) {
> > instead of 'prog->prog_type'
> 
> Yes, absolutely, thanks!

So I have applied that as a merge fix patch.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpy_2PAnEAWy.pgp
Description: OpenPGP digital signature

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

[Daniel Borkmann]

On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:

On 4/7/15 4:13 AM, Daniel Borkmann wrote:

[ Cc'ing Dave, fyi ]

On 04/07/2015 11:05 AM, Stephen Rothwell wrote:

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
 wrote:

On 04/07/2015 10:48 AM, Ingo Molnar wrote:

* Stephen Rothwell  wrote:


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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
member named 'prog_type'
if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
 ^

Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
attached to kprobes").


Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?


Note, this is a merge conflict with the work that went via net-next
tree,
i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {


Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.


Yes, indeed, depending which tree is merged first.


Daniel analysis is correct, but the fix for kernel/events/core.c
should be:
- if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
+ if (prog->type != BPF_PROG_TYPE_KPROBE) {
instead of 'prog->prog_type'


Yes, absolutely, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alexei Starovoitov]

On 4/7/15 4:13 AM, Daniel Borkmann wrote:

[ Cc'ing Dave, fyi ]

On 04/07/2015 11:05 AM, Stephen Rothwell wrote:

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
 wrote:

On 04/07/2015 10:48 AM, Ingo Molnar wrote:

* Stephen Rothwell  wrote:


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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
member named 'prog_type'
if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
 ^

Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
attached to kprobes").


Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?


Note, this is a merge conflict with the work that went via net-next
tree,
i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {


Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.


Yes, indeed, depending which tree is merged first.


Daniel analysis is correct, but the fix for kernel/events/core.c
should be:
- if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
+ if (prog->type != BPF_PROG_TYPE_KPROBE) {
instead of 'prog->prog_type'

Thanks Stephen!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Daniel Borkmann]

[ Cc'ing Dave, fyi ]

On 04/07/2015 11:05 AM, Stephen Rothwell wrote:

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann  wrote:

On 04/07/2015 10:48 AM, Ingo Molnar wrote:

* Stephen Rothwell  wrote:


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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 
'prog_type'
if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
 ^

Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
attached to kprobes").


Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?


Note, this is a merge conflict with the work that went via net-next tree,
i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {


Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.


Yes, indeed, depending which tree is merged first.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Daniel,

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann  wrote:
>
> On 04/07/2015 10:48 AM, Ingo Molnar wrote:
> >
> > * Stephen Rothwell  wrote:
> >
> >> After merging the tip tree, today's linux-next build (powerpc
> >> ppc64_defconfig) failed like this:
> >>
> >> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> >> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member 
> >> named 'prog_type'
> >>if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
> >> ^
> >>
> >> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> >> attached to kprobes").
> >
> > Note, this must be some (rarely triggered) aspect of the ppc64
> > defconfig that neither x86 randconfigs nor most other arch defconfigs
> > expose?
> 
> Note, this is a merge conflict with the work that went via net-next tree,
> i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
> bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.
> 
> You should be able to resolve it in linux-next by changing the test to:
> 
>if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {

Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpJcCiA7Qe3x.pgp
Description: OpenPGP digital signature

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

[Daniel Borkmann]

On 04/07/2015 10:48 AM, Ingo Molnar wrote:


* Stephen Rothwell  wrote:


Hi all,

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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 
'prog_type'
   if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
^

Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
attached to kprobes").


Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?


Note, this is a merge conflict with the work that went via net-next tree,
i.e. 24701ecea76b ("ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux"). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

  if (prog->prog_type != BPF_PROG_TYPE_KPROBE) {

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Zijlstra]

On Tue, Apr 07, 2015 at 05:18:58PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member 
> named 'prog_type'
>   if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>^
> 
> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes").
> 
> I have used the tip tree from next-20150402 for today.

Hmm, tip/master builds fine on ppc64 for me, but does something like the
below help?

---
Subject: perf: Fix BPF filter crud

The BPF filter crud got its CONFIG deps wrong, fix it.

Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/events/core.c |   37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 06917d5..1d94b92 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6711,6 +6711,25 @@ static void perf_event_free_filter(struct perf_event 
*event)
ftrace_profile_free_filter(event);
 }
 
+#else /* EVENT_TRACING */
+
+static inline void perf_tp_register(void)
+{
+}
+
+static int perf_event_set_filter(struct perf_event *event, void __user *arg)
+{
+   return -ENOENT;
+}
+
+static void perf_event_free_filter(struct perf_event *event)
+{
+}
+
+#endif /* EVENT_TRACING */
+
+#if defined CONFIG_BPF_EVENTS && defined CONFIG_EVENT_TRACING
+
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
struct bpf_prog *prog;
@@ -6754,20 +6773,7 @@ static void perf_event_free_bpf_prog(struct perf_event 
*event)
}
 }
 
-#else
-
-static inline void perf_tp_register(void)
-{
-}
-
-static int perf_event_set_filter(struct perf_event *event, void __user *arg)
-{
-   return -ENOENT;
-}
-
-static void perf_event_free_filter(struct perf_event *event)
-{
-}
+#else /* BPF_EVENTS && EVENT_TRACING */
 
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
@@ -6777,7 +6783,8 @@ static int perf_event_set_bpf_prog(struct perf_event 
*event, u32 prog_fd)
 static void perf_event_free_bpf_prog(struct perf_event *event)
 {
 }
-#endif /* CONFIG_EVENT_TRACING */
+
+#endif /* BPF_EVENTS && EVENT_TRACING */
 
 #ifdef CONFIG_HAVE_HW_BREAKPOINT
 void perf_bp_event(struct perf_event *bp, void *data)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/events/core.c: In function 'perf_event_set_bpf_prog':
> kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member 
> named 'prog_type'
>   if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
>^
> 
> Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
> attached to kprobes").

Note, this must be some (rarely triggered) aspect of the ppc64 
defconfig that neither x86 randconfigs nor most other arch defconfigs 
expose?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 
'prog_type'
  if (prog->aux->prog_type != BPF_PROG_TYPE_KPROBE) {
   ^

Caused by commit 2541517c32be ("tracing, perf: Implement BPF programs
attached to kprobes").

I have used the tip tree from next-20150402 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpSJh03FJhqG.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 
'prog_type'
  if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
   ^

Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
attached to kprobes).

I have used the tip tree from next-20150402 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpSJh03FJhqG.pgp
Description: OpenPGP digital signature

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

[Ingo Molnar]

* Stephen Rothwell s...@canb.auug.org.au wrote:

 Hi all,
 
 After merging the tip tree, today's linux-next build (powerpc
 ppc64_defconfig) failed like this:
 
 kernel/events/core.c: In function 'perf_event_set_bpf_prog':
 kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member 
 named 'prog_type'
   if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
^
 
 Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
 attached to kprobes).

Note, this must be some (rarely triggered) aspect of the ppc64 
defconfig that neither x86 randconfigs nor most other arch defconfigs 
expose?

Thanks,

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Peter Zijlstra]

On Tue, Apr 07, 2015 at 05:18:58PM +1000, Stephen Rothwell wrote:
 Hi all,
 
 After merging the tip tree, today's linux-next build (powerpc
 ppc64_defconfig) failed like this:
 
 kernel/events/core.c: In function 'perf_event_set_bpf_prog':
 kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member 
 named 'prog_type'
   if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
^
 
 Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
 attached to kprobes).
 
 I have used the tip tree from next-20150402 for today.

Hmm, tip/master builds fine on ppc64 for me, but does something like the
below help?

---
Subject: perf: Fix BPF filter crud

The BPF filter crud got its CONFIG deps wrong, fix it.

Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
---
 kernel/events/core.c |   37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 06917d5..1d94b92 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6711,6 +6711,25 @@ static void perf_event_free_filter(struct perf_event 
*event)
ftrace_profile_free_filter(event);
 }
 
+#else /* EVENT_TRACING */
+
+static inline void perf_tp_register(void)
+{
+}
+
+static int perf_event_set_filter(struct perf_event *event, void __user *arg)
+{
+   return -ENOENT;
+}
+
+static void perf_event_free_filter(struct perf_event *event)
+{
+}
+
+#endif /* EVENT_TRACING */
+
+#if defined CONFIG_BPF_EVENTS  defined CONFIG_EVENT_TRACING
+
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
struct bpf_prog *prog;
@@ -6754,20 +6773,7 @@ static void perf_event_free_bpf_prog(struct perf_event 
*event)
}
 }
 
-#else
-
-static inline void perf_tp_register(void)
-{
-}
-
-static int perf_event_set_filter(struct perf_event *event, void __user *arg)
-{
-   return -ENOENT;
-}
-
-static void perf_event_free_filter(struct perf_event *event)
-{
-}
+#else /* BPF_EVENTS  EVENT_TRACING */
 
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
@@ -6777,7 +6783,8 @@ static int perf_event_set_bpf_prog(struct perf_event 
*event, u32 prog_fd)
 static void perf_event_free_bpf_prog(struct perf_event *event)
 {
 }
-#endif /* CONFIG_EVENT_TRACING */
+
+#endif /* BPF_EVENTS  EVENT_TRACING */
 
 #ifdef CONFIG_HAVE_HW_BREAKPOINT
 void perf_bp_event(struct perf_event *bp, void *data)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Daniel,

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann dan...@iogearbox.net wrote:

 On 04/07/2015 10:48 AM, Ingo Molnar wrote:
 
  * Stephen Rothwell s...@canb.auug.org.au wrote:
 
  After merging the tip tree, today's linux-next build (powerpc
  ppc64_defconfig) failed like this:
 
  kernel/events/core.c: In function 'perf_event_set_bpf_prog':
  kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member 
  named 'prog_type'
 if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
  ^
 
  Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
  attached to kprobes).
 
  Note, this must be some (rarely triggered) aspect of the ppc64
  defconfig that neither x86 randconfigs nor most other arch defconfigs
  expose?
 
 Note, this is a merge conflict with the work that went via net-next tree,
 i.e. 24701ecea76b (ebpf: move read-only fields to bpf_prog and shrink
 bpf_prog_aux). I believe that is why it didn't trigger on tip tree.
 
 You should be able to resolve it in linux-next by changing the test to:
 
if (prog-prog_type != BPF_PROG_TYPE_KPROBE) {

Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpJcCiA7Qe3x.pgp
Description: OpenPGP digital signature

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

[Daniel Borkmann]

On 04/07/2015 10:48 AM, Ingo Molnar wrote:


* Stephen Rothwell s...@canb.auug.org.au wrote:


Hi all,

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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 
'prog_type'
   if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
^

Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
attached to kprobes).


Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?


Note, this is a merge conflict with the work that went via net-next tree,
i.e. 24701ecea76b (ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

  if (prog-prog_type != BPF_PROG_TYPE_KPROBE) {

Thanks,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Daniel Borkmann]

[ Cc'ing Dave, fyi ]

On 04/07/2015 11:05 AM, Stephen Rothwell wrote:

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann dan...@iogearbox.net wrote:

On 04/07/2015 10:48 AM, Ingo Molnar wrote:

* Stephen Rothwell s...@canb.auug.org.au wrote:


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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no member named 
'prog_type'
if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
 ^

Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
attached to kprobes).


Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?


Note, this is a merge conflict with the work that went via net-next tree,
i.e. 24701ecea76b (ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

if (prog-prog_type != BPF_PROG_TYPE_KPROBE) {


Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.


Yes, indeed, depending which tree is merged first.

Thanks,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alexei Starovoitov]

On 4/7/15 4:13 AM, Daniel Borkmann wrote:

[ Cc'ing Dave, fyi ]

On 04/07/2015 11:05 AM, Stephen Rothwell wrote:

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
dan...@iogearbox.net wrote:

On 04/07/2015 10:48 AM, Ingo Molnar wrote:

* Stephen Rothwell s...@canb.auug.org.au wrote:


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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
member named 'prog_type'
if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
 ^

Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
attached to kprobes).


Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?


Note, this is a merge conflict with the work that went via net-next
tree,
i.e. 24701ecea76b (ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

if (prog-prog_type != BPF_PROG_TYPE_KPROBE) {


Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.


Yes, indeed, depending which tree is merged first.


Daniel analysis is correct, but the fix for kernel/events/core.c
should be:
- if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
+ if (prog-type != BPF_PROG_TYPE_KPROBE) {
instead of 'prog-prog_type'

Thanks Stephen!

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Daniel Borkmann]

On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:

On 4/7/15 4:13 AM, Daniel Borkmann wrote:

[ Cc'ing Dave, fyi ]

On 04/07/2015 11:05 AM, Stephen Rothwell wrote:

On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
dan...@iogearbox.net wrote:

On 04/07/2015 10:48 AM, Ingo Molnar wrote:

* Stephen Rothwell s...@canb.auug.org.au wrote:


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

kernel/events/core.c: In function 'perf_event_set_bpf_prog':
kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
member named 'prog_type'
if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
 ^

Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
attached to kprobes).


Note, this must be some (rarely triggered) aspect of the ppc64
defconfig that neither x86 randconfigs nor most other arch defconfigs
expose?


Note, this is a merge conflict with the work that went via net-next
tree,
i.e. 24701ecea76b (ebpf: move read-only fields to bpf_prog and shrink
bpf_prog_aux). I believe that is why it didn't trigger on tip tree.

You should be able to resolve it in linux-next by changing the test to:

if (prog-prog_type != BPF_PROG_TYPE_KPROBE) {


Thanks Daniel, I will do that tomorrow.  Someone will have to remember
to tell Linus.


Yes, indeed, depending which tree is merged first.


Daniel analysis is correct, but the fix for kernel/events/core.c
should be:
- if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
+ if (prog-type != BPF_PROG_TYPE_KPROBE) {
instead of 'prog-prog_type'


Yes, absolutely, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

On Tue, 07 Apr 2015 21:54:05 +0200 Daniel Borkmann dan...@iogearbox.net wrote:

 On 04/07/2015 06:18 PM, Alexei Starovoitov wrote:
  On 4/7/15 4:13 AM, Daniel Borkmann wrote:
  [ Cc'ing Dave, fyi ]
 
  On 04/07/2015 11:05 AM, Stephen Rothwell wrote:
  On Tue, 07 Apr 2015 10:56:13 +0200 Daniel Borkmann
  dan...@iogearbox.net wrote:
  On 04/07/2015 10:48 AM, Ingo Molnar wrote:
  * Stephen Rothwell s...@canb.auug.org.au wrote:
 
  After merging the tip tree, today's linux-next build (powerpc
  ppc64_defconfig) failed like this:
 
  kernel/events/core.c: In function 'perf_event_set_bpf_prog':
  kernel/events/core.c:6732:15: error: 'struct bpf_prog_aux' has no
  member named 'prog_type'
  if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
   ^
 
  Caused by commit 2541517c32be (tracing, perf: Implement BPF programs
  attached to kprobes).
 
  Note, this must be some (rarely triggered) aspect of the ppc64
  defconfig that neither x86 randconfigs nor most other arch defconfigs
  expose?
 
  Note, this is a merge conflict with the work that went via net-next
  tree,
  i.e. 24701ecea76b (ebpf: move read-only fields to bpf_prog and shrink
  bpf_prog_aux). I believe that is why it didn't trigger on tip tree.
 
  You should be able to resolve it in linux-next by changing the test to:
 
  if (prog-prog_type != BPF_PROG_TYPE_KPROBE) {
 
  Thanks Daniel, I will do that tomorrow.  Someone will have to remember
  to tell Linus.
 
  Yes, indeed, depending which tree is merged first.
 
  Daniel analysis is correct, but the fix for kernel/events/core.c
  should be:
  - if (prog-aux-prog_type != BPF_PROG_TYPE_KPROBE) {
  + if (prog-type != BPF_PROG_TYPE_KPROBE) {
  instead of 'prog-prog_type'
 
 Yes, absolutely, thanks!

So I have applied that as a merge fix patch.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpy_2PAnEAWy.pgp
Description: OpenPGP digital signature

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

[Nathan Lynch]

On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
>> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
>>> Hi Russell,
>>>
>>> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
>>>  wrote:

 I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
 it in my tree and keep my tree buildable without dragging in the tip
 tree.
>>>
>>> Does it affect your tree on its own?  If not, then it can be fixed when
>>> merged as I have done, or if you look at the tip tree, all you really
>>> need to merge is tip timers/core branch (which I am sure the tip guys
>>> can tell you if it is stable enough) which is about 28 commits ...
>>>
 The ARM VDSO stuff will just have to wait for 4.2 instead.
>>>
>>> If that works for you.
>>
>> FWIW, Stephen's merge fix is correct and I have run my vdso tests
>> without problems on OMAP5 with next-20150330.
> 
> Hopefully, I can pull the tip stuff but if not, I'll try to remember
> to include Stephen's patch with my pull request, but I can't make any
> guarantees - Stephen's email will very quickly get buried in my mailbox,
> and I'll most likely forget about it too... I'm notoriously bad with
> email...

OK, let me know if I can help.

I'm happy to remind you about it when the merge window opens.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Russell King - ARM Linux]

On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
> On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> > Hi Russell,
> > 
> > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
> >  wrote:
> >>
> >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> >> it in my tree and keep my tree buildable without dragging in the tip
> >> tree.
> > 
> > Does it affect your tree on its own?  If not, then it can be fixed when
> > merged as I have done, or if you look at the tip tree, all you really
> > need to merge is tip timers/core branch (which I am sure the tip guys
> > can tell you if it is stable enough) which is about 28 commits ...
> > 
> >> The ARM VDSO stuff will just have to wait for 4.2 instead.
> > 
> > If that works for you.
> 
> FWIW, Stephen's merge fix is correct and I have run my vdso tests
> without problems on OMAP5 with next-20150330.

Hopefully, I can pull the tip stuff but if not, I'll try to remember
to include Stephen's patch with my pull request, but I can't make any
guarantees - Stephen's email will very quickly get buried in my mailbox,
and I'll most likely forget about it too... I'm notoriously bad with
email...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Nathan Lynch]

On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
> Hi Russell,
> 
> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
>  wrote:
>>
>> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
>> it in my tree and keep my tree buildable without dragging in the tip
>> tree.
> 
> Does it affect your tree on its own?  If not, then it can be fixed when
> merged as I have done, or if you look at the tip tree, all you really
> need to merge is tip timers/core branch (which I am sure the tip guys
> can tell you if it is stable enough) which is about 28 commits ...
> 
>> The ARM VDSO stuff will just have to wait for 4.2 instead.
> 
> If that works for you.

FWIW, Stephen's merge fix is correct and I have run my vdso tests
without problems on OMAP5 with next-20150330.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Russell,

On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
 wrote:
>
> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
> it in my tree and keep my tree buildable without dragging in the tip
> tree.

Does it affect your tree on its own?  If not, then it can be fixed when
merged as I have done, or if you look at the tip tree, all you really
need to merge is tip timers/core branch (which I am sure the tip guys
can tell you if it is stable enough) which is about 28 commits ...

> The ARM VDSO stuff will just have to wait for 4.2 instead.

If that works for you.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpDPEYPRkxXw.pgp
Description: OpenPGP digital signature

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

[Russell King - ARM Linux]

On Mon, Mar 30, 2015 at 05:13:34PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
> arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member 
> named 'tkr'
>   if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
>^
> arch/arm/kernel/vdso.c: In function 'update_vsyscall':
> arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 
> 'tkr'
>vdso_data->cs_cycle_last = tk->tkr.cycle_last;
> ^
> arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 
> 'tkr'
>vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec;
> ^
> arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 
> 'tkr'
>vdso_data->cs_mult  = tk->tkr.mult;
>^
> arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 
> 'tkr'
>vdso_data->cs_shift  = tk->tkr.shift;
> ^
> arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 
> 'tkr'
>vdso_data->cs_mask  = tk->tkr.mask;
>^
> 
> Caused by commit 876e78818def ("time: Rename timekeeper::tkr to
> timekeeper::tkr_mono") from the tip tree interacting with commit
> ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and
> synchronization") from the arm tree.
> 
> I added this merge fix patch for today (is that all that is needed?):

I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
it in my tree and keep my tree buildable without dragging in the tip
tree.

The ARM VDSO stuff will just have to wait for 4.2 instead.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member 
named 'tkr'
  if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
   ^
arch/arm/kernel/vdso.c: In function 'update_vsyscall':
arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data->cs_cycle_last = tk->tkr.cycle_last;
^
arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data->xtime_clock_snsec = tk->tkr.xtime_nsec;
^
arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data->cs_mult  = tk->tkr.mult;
   ^
arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data->cs_shift  = tk->tkr.shift;
^
arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data->cs_mask  = tk->tkr.mask;
   ^

Caused by commit 876e78818def ("time: Rename timekeeper::tkr to
timekeeper::tkr_mono") from the tip tree interacting with commit
ecf99a439105 ("ARM: 8331/1: VDSO initialization, mapping, and
synchronization") from the arm tree.

I added this merge fix patch for today (is that all that is needed?):

From: Stephen Rothwell 
Date: Mon, 30 Mar 2015 17:08:21 +1100
Subject: [PATCH] ARM: VDSO: rename tkr to tkr_mono

Signed-off-by: Stephen Rothwell 
---
 arch/arm/kernel/vdso.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 0d31d3ccab81..efe17dd9b921 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
return false;
 
-   if (strcmp(tk->tkr.clock->name, "arch_sys_counter") != 0)
+   if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0)
return false;
 
return true;
@@ -316,12 +316,12 @@ void update_vsyscall(struct timekeeper *tk)
vdso_data->wtm_clock_nsec   = wtm->tv_nsec;
 
if (vdso_data->tk_is_cntvct) {
-   vdso_data->cs_cycle_last= tk->tkr.cycle_last;
+   vdso_data->cs_cycle_last= tk->tkr_mono.cycle_last;
vdso_data->xtime_clock_sec  = tk->xtime_sec;
-   vdso_data->xtime_clock_snsec= tk->tkr.xtime_nsec;
-   vdso_data->cs_mult  = tk->tkr.mult;
-   vdso_data->cs_shift = tk->tkr.shift;
-   vdso_data->cs_mask  = tk->tkr.mask;
+   vdso_data->xtime_clock_snsec= tk->tkr_mono.xtime_nsec;
+   vdso_data->cs_mult  = tk->tkr_mono.mult;
+   vdso_data->cs_shift = tk->tkr_mono.shift;
+   vdso_data->cs_mask  = tk->tkr_mono.mask;
}
 
vdso_write_end(vdso_data);
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpcrYnb2lkzW.pgp
Description: OpenPGP digital signature

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

[Russell King - ARM Linux]

On Mon, Mar 30, 2015 at 05:13:34PM +1100, Stephen Rothwell wrote:
 Hi all,
 
 After merging the tip tree, today's linux-next build (arm
 multi_v7_defconfig) failed like this:
 
 arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
 arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member 
 named 'tkr'
   if (strcmp(tk-tkr.clock-name, arch_sys_counter) != 0)
^
 arch/arm/kernel/vdso.c: In function 'update_vsyscall':
 arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 
 'tkr'
vdso_data-cs_cycle_last = tk-tkr.cycle_last;
 ^
 arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 
 'tkr'
vdso_data-xtime_clock_snsec = tk-tkr.xtime_nsec;
 ^
 arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 
 'tkr'
vdso_data-cs_mult  = tk-tkr.mult;
^
 arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 
 'tkr'
vdso_data-cs_shift  = tk-tkr.shift;
 ^
 arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 
 'tkr'
vdso_data-cs_mask  = tk-tkr.mask;
^
 
 Caused by commit 876e78818def (time: Rename timekeeper::tkr to
 timekeeper::tkr_mono) from the tip tree interacting with commit
 ecf99a439105 (ARM: 8331/1: VDSO initialization, mapping, and
 synchronization) from the arm tree.
 
 I added this merge fix patch for today (is that all that is needed?):

I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
it in my tree and keep my tree buildable without dragging in the tip
tree.

The ARM VDSO stuff will just have to wait for 4.2 instead.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

arch/arm/kernel/vdso.c: In function 'tk_is_cntvct':
arch/arm/kernel/vdso.c:273:15: error: 'const struct timekeeper' has no member 
named 'tkr'
  if (strcmp(tk-tkr.clock-name, arch_sys_counter) != 0)
   ^
arch/arm/kernel/vdso.c: In function 'update_vsyscall':
arch/arm/kernel/vdso.c:319:32: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data-cs_cycle_last = tk-tkr.cycle_last;
^
arch/arm/kernel/vdso.c:321:36: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data-xtime_clock_snsec = tk-tkr.xtime_nsec;
^
arch/arm/kernel/vdso.c:322:27: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data-cs_mult  = tk-tkr.mult;
   ^
arch/arm/kernel/vdso.c:323:28: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data-cs_shift  = tk-tkr.shift;
^
arch/arm/kernel/vdso.c:324:27: error: 'struct timekeeper' has no member named 
'tkr'
   vdso_data-cs_mask  = tk-tkr.mask;
   ^

Caused by commit 876e78818def (time: Rename timekeeper::tkr to
timekeeper::tkr_mono) from the tip tree interacting with commit
ecf99a439105 (ARM: 8331/1: VDSO initialization, mapping, and
synchronization) from the arm tree.

I added this merge fix patch for today (is that all that is needed?):

From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 30 Mar 2015 17:08:21 +1100
Subject: [PATCH] ARM: VDSO: rename tkr to tkr_mono

Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
 arch/arm/kernel/vdso.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 0d31d3ccab81..efe17dd9b921 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
return false;
 
-   if (strcmp(tk-tkr.clock-name, arch_sys_counter) != 0)
+   if (strcmp(tk-tkr_mono.clock-name, arch_sys_counter) != 0)
return false;
 
return true;
@@ -316,12 +316,12 @@ void update_vsyscall(struct timekeeper *tk)
vdso_data-wtm_clock_nsec   = wtm-tv_nsec;
 
if (vdso_data-tk_is_cntvct) {
-   vdso_data-cs_cycle_last= tk-tkr.cycle_last;
+   vdso_data-cs_cycle_last= tk-tkr_mono.cycle_last;
vdso_data-xtime_clock_sec  = tk-xtime_sec;
-   vdso_data-xtime_clock_snsec= tk-tkr.xtime_nsec;
-   vdso_data-cs_mult  = tk-tkr.mult;
-   vdso_data-cs_shift = tk-tkr.shift;
-   vdso_data-cs_mask  = tk-tkr.mask;
+   vdso_data-xtime_clock_snsec= tk-tkr_mono.xtime_nsec;
+   vdso_data-cs_mult  = tk-tkr_mono.mult;
+   vdso_data-cs_shift = tk-tkr_mono.shift;
+   vdso_data-cs_mask  = tk-tkr_mono.mask;
}
 
vdso_write_end(vdso_data);
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpcrYnb2lkzW.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Russell,

On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
li...@arm.linux.org.uk wrote:

 I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
 it in my tree and keep my tree buildable without dragging in the tip
 tree.

Does it affect your tree on its own?  If not, then it can be fixed when
merged as I have done, or if you look at the tip tree, all you really
need to merge is tip timers/core branch (which I am sure the tip guys
can tell you if it is stable enough) which is about 28 commits ...

 The ARM VDSO stuff will just have to wait for 4.2 instead.

If that works for you.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpDPEYPRkxXw.pgp
Description: OpenPGP digital signature

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

[Nathan Lynch]

On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
 Hi Russell,
 
 On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
 li...@arm.linux.org.uk wrote:

 I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
 it in my tree and keep my tree buildable without dragging in the tip
 tree.
 
 Does it affect your tree on its own?  If not, then it can be fixed when
 merged as I have done, or if you look at the tip tree, all you really
 need to merge is tip timers/core branch (which I am sure the tip guys
 can tell you if it is stable enough) which is about 28 commits ...
 
 The ARM VDSO stuff will just have to wait for 4.2 instead.
 
 If that works for you.

FWIW, Stephen's merge fix is correct and I have run my vdso tests
without problems on OMAP5 with next-20150330.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Russell King - ARM Linux]

On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
 On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
  Hi Russell,
  
  On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
  li...@arm.linux.org.uk wrote:
 
  I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
  it in my tree and keep my tree buildable without dragging in the tip
  tree.
  
  Does it affect your tree on its own?  If not, then it can be fixed when
  merged as I have done, or if you look at the tip tree, all you really
  need to merge is tip timers/core branch (which I am sure the tip guys
  can tell you if it is stable enough) which is about 28 commits ...
  
  The ARM VDSO stuff will just have to wait for 4.2 instead.
  
  If that works for you.
 
 FWIW, Stephen's merge fix is correct and I have run my vdso tests
 without problems on OMAP5 with next-20150330.

Hopefully, I can pull the tip stuff but if not, I'll try to remember
to include Stephen's patch with my pull request, but I can't make any
guarantees - Stephen's email will very quickly get buried in my mailbox,
and I'll most likely forget about it too... I'm notoriously bad with
email...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Nathan Lynch]

On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote:
 On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote:
 On 03/30/2015 03:08 AM, Stephen Rothwell wrote:
 Hi Russell,

 On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux 
 li...@arm.linux.org.uk wrote:

 I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep
 it in my tree and keep my tree buildable without dragging in the tip
 tree.

 Does it affect your tree on its own?  If not, then it can be fixed when
 merged as I have done, or if you look at the tip tree, all you really
 need to merge is tip timers/core branch (which I am sure the tip guys
 can tell you if it is stable enough) which is about 28 commits ...

 The ARM VDSO stuff will just have to wait for 4.2 instead.

 If that works for you.

 FWIW, Stephen's merge fix is correct and I have run my vdso tests
 without problems on OMAP5 with next-20150330.
 
 Hopefully, I can pull the tip stuff but if not, I'll try to remember
 to include Stephen's patch with my pull request, but I can't make any
 guarantees - Stephen's email will very quickly get buried in my mailbox,
 and I'll most likely forget about it too... I'm notoriously bad with
 email...

OK, let me know if I can help.

I'm happy to remind you about it when the merge window opens.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[John Stultz]

On 07/29/2014 04:56 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell
 wrote:
>>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> arch/powerpc/kernel/time.c:743:6: error: conflicting types for
'update_vsyscall_old'
>>  void update_vsyscall_old(struct timespec *wall_time, struct timespec
*wtm,
>>   ^
>> In file included from arch/powerpc/kernel/time.c:77:0:
>> include/linux/timekeeper_internal.h:114:13: note: previous
declaration of 'update_vsyscall_old' was here
>>  extern void update_vsyscall_old(struct timespec *ts, struct timespec
*wtm,
>>  ^
>>
>> Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").
>>
>> I have used the tip tree from next-20140724 for today.
>
> Ping?
So I sent a fix for this the other day ([PATCH] timekeeping: Fixup typo
in update_vsyscall_old definition), but I've not heard anything from
anyone on it.


thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> arch/powerpc/kernel/time.c:743:6: error: conflicting types for 
> 'update_vsyscall_old'
>  void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm,
>   ^
> In file included from arch/powerpc/kernel/time.c:77:0:
> include/linux/timekeeper_internal.h:114:13: note: previous declaration of 
> 'update_vsyscall_old' was here
>  extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
>  ^
> 
> Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").
> 
> I have used the tip tree from next-20140724 for today.

Ping?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 Hi all,
 
 After merging the tip tree, today's linux-next build (powerpc
 ppc64_defconfig) failed like this:
 
 arch/powerpc/kernel/time.c:743:6: error: conflicting types for 
 'update_vsyscall_old'
  void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm,
   ^
 In file included from arch/powerpc/kernel/time.c:77:0:
 include/linux/timekeeper_internal.h:114:13: note: previous declaration of 
 'update_vsyscall_old' was here
  extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
  ^
 
 Caused by commit 4a0e637738f0 (clocksource: Get rid of cycle_last).
 
 I have used the tip tree from next-20140724 for today.

Ping?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

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

[John Stultz]

On 07/29/2014 04:56 PM, Stephen Rothwell wrote:
 Hi all,

 On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell
s...@canb.auug.org.au wrote:

 Hi all,

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

 arch/powerpc/kernel/time.c:743:6: error: conflicting types for
'update_vsyscall_old'
  void update_vsyscall_old(struct timespec *wall_time, struct timespec
*wtm,
   ^
 In file included from arch/powerpc/kernel/time.c:77:0:
 include/linux/timekeeper_internal.h:114:13: note: previous
declaration of 'update_vsyscall_old' was here
  extern void update_vsyscall_old(struct timespec *ts, struct timespec
*wtm,
  ^

 Caused by commit 4a0e637738f0 (clocksource: Get rid of cycle_last).

 I have used the tip tree from next-20140724 for today.

 Ping?
So I sent a fix for this the other day ([PATCH] timekeeping: Fixup typo
in update_vsyscall_old definition), but I've not heard anything from
anyone on it.


thanks
-john

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

arch/powerpc/kernel/time.c:743:6: error: conflicting types for 
'update_vsyscall_old'
 void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm,
  ^
In file included from arch/powerpc/kernel/time.c:77:0:
include/linux/timekeeper_internal.h:114:13: note: previous declaration of 
'update_vsyscall_old' was here
 extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
 ^

Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").

I have used the tip tree from next-20140724 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

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

arch/powerpc/kernel/time.c:743:6: error: conflicting types for 
'update_vsyscall_old'
 void update_vsyscall_old(struct timespec *wall_time, struct timespec *wtm,
  ^
In file included from arch/powerpc/kernel/time.c:77:0:
include/linux/timekeeper_internal.h:114:13: note: previous declaration of 
'update_vsyscall_old' was here
 extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
 ^

Caused by commit 4a0e637738f0 (clocksource: Get rid of cycle_last).

I have used the tip tree from next-20140724 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature