Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: build warning after merge of the tip tree
@ 2020-05-19  6:57 Stephen Rothwell
  2020-05-19  7:12 ` Steve French
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2020-05-19  6:57 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Steve French, CIFS


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

Hi all,

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

fs/cifs/smb2inode.c: In function 'smb2_compound_op':
fs/cifs/smb2inode.c:424:1: warning: the frame size of 2736 bytes is larger than 2048 bytes [-Wframe-larger-than=]
  424 | }
      | ^

I have no idea what caused this.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-05-19  6:57 linux-next: build warning after merge of the tip tree Stephen Rothwell
@ 2020-05-19  7:12 ` Steve French
  0 siblings, 0 replies; 113+ messages in thread
From: Steve French @ 2020-05-19  7:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, CIFS,
	ronnie sahlberg

Ronnie mentioned that he will take a look ...

On Tue, May 19, 2020 at 1:57 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> fs/cifs/smb2inode.c: In function 'smb2_compound_op':
> fs/cifs/smb2inode.c:424:1: warning: the frame size of 2736 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>   424 | }
>       | ^
>
> I have no idea what caused this.
>
> --
> Cheers,
> Stephen Rothwell



-- 
Thanks,

Steve

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2020-05-21 11:56 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2020-05-21 11:56 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List


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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:

arch/x86/kernel/traps.c: In function 'exc_double_fault':
arch/x86/kernel/traps.c:332:16: warning: unused variable 'address' [-Wunused-variable]
  332 |  unsigned long address = read_cr2();
      |                ^~~~~~~

Introduced by commit

  095b7a3e7745 ("x86/entry: Convert double fault exception to IDTENTRY_DF")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2020-04-28  6:29 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2020-04-28  6:29 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Josh Poimboeuf


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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:

arch/x86/kernel/unwind_orc.c:29:26: warning: 'cur_orc_table' defined but not used [-Wunused-variable]
   29 | static struct orc_entry *cur_orc_table = __start_orc_unwind;
      |                          ^~~~~~~~~~~~~
arch/x86/kernel/unwind_orc.c:28:13: warning: 'cur_orc_ip_table' defined but not used [-Wunused-variable]
   28 | static int *cur_orc_ip_table = __start_orc_unwind_ip;
      |             ^~~~~~~~~~~~~~~~

Exposed by commit

  153eb2223c79 ("x86/unwind/orc: Convert global variables to static")

This build has CONFIG_MODULE not set.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-04-13  0:01         ` Stephen Rothwell
@ 2020-04-14  8:42           ` Thomas Gleixner
  0 siblings, 0 replies; 113+ messages in thread
From: Thomas Gleixner @ 2020-04-14  8:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, Al Viro

Stephen,

Stephen Rothwell <sfr@canb.auug.org.au> writes:
> On Thu, 02 Apr 2020 00:39:55 +0200 Thomas Gleixner <tglx@linutronix.de> wrote:
>> and the below proves it:
>> 
>> diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
>> index e133da303a98..a9151884bc85 100644
>> --- a/arch/arm/include/asm/futex.h
>> +++ b/arch/arm/include/asm/futex.h
>> @@ -165,8 +165,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
>>  	preempt_enable();
>>  #endif
>>  
>> -	if (!ret)
>> -		*oval = oldval;
>> +	/*
>> +	 * Store unconditionally. If ret != 0 the extra store is the least
>> +	 * of the worries but GCC cannot figure out that __futex_atomic_op()
>> +	 * is either setting ret to -EFAULT or storing the old value in
>> +	 * oldval which results in a uninitialized warning at the call site.
>> +	 */
>> +	*oval = oldval;
>>  
>>  	return ret;
>>  }
>> 
>> I think that's the right thing to do anyway. The conditional is pointless.
>
> Thanks for the analysis.
>
> I am still getting this warning, now from Linus' tree builds.

Yeah. Just noticed that both of us failed to CC the arm folks. :(

Let me send out a proper patch.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-04-01 22:39       ` Thomas Gleixner
@ 2020-04-13  0:01         ` Stephen Rothwell
  2020-04-14  8:42           ` Thomas Gleixner
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2020-04-13  0:01 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, Al Viro


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

Hi Thomas,

On Thu, 02 Apr 2020 00:39:55 +0200 Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > On Wed, 01 Apr 2020 12:25:25 +0200 Thomas Gleixner <tglx@linutronix.de> wrote:  
> >> Me neither. Which compiler version?  
> >
> > arm-linux-gnueabi-gcc (Debian 9.2.1-21) 9.2.1 20191130
> >  
> >> I'm using arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0 which does not
> >> show that oddity.  
> >
> > I assume it is because of the change to arch_futex_atomic_op_inuser()
> > for arm and the compiler is not clever enough to work out that the early
> > return from arch_futex_atomic_op_inuser() means that oldval is not
> > referenced in its caller.  
> 
> Actually no. It's the ASM part which causes this. With the following
> hack applied it compiles:
> 
> diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
> index e133da303a98..2c6b40f71009 100644
> --- a/arch/arm/include/asm/futex.h
> +++ b/arch/arm/include/asm/futex.h
> @@ -132,7 +132,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
>  static inline int
>  arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
>  {
> -	int oldval = 0, ret, tmp;
> +	int oldval = 0, ret;
>  
>  	if (!access_ok(uaddr, sizeof(u32)))
>  		return -EFAULT;
> @@ -142,6 +142,7 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
>  #endif
>  
>  	switch (op) {
> +#if 0
>  	case FUTEX_OP_SET:
>  		__futex_atomic_op("mov	%0, %4", ret, oldval, tmp, uaddr, oparg);
>  		break;
> @@ -157,6 +158,7 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
>  	case FUTEX_OP_XOR:
>  		__futex_atomic_op("eor	%0, %1, %4", ret, oldval, tmp, uaddr, oparg);
>  		break;
> +#endif
>  	default:
>  		ret = -ENOSYS;
>  	}
> 
> but with this is emits the warning:
> 
> diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
> index e133da303a98..5191d7b61b83 100644
> --- a/arch/arm/include/asm/futex.h
> +++ b/arch/arm/include/asm/futex.h
> @@ -145,6 +145,7 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
>  	case FUTEX_OP_SET:
>  		__futex_atomic_op("mov	%0, %4", ret, oldval, tmp, uaddr, oparg);
>  		break;
> +#if 0
>  	case FUTEX_OP_ADD:
>  		__futex_atomic_op("add	%0, %1, %4", ret, oldval, tmp, uaddr, oparg);
>  		break;
> @@ -157,6 +158,7 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
>  	case FUTEX_OP_XOR:
>  		__futex_atomic_op("eor	%0, %1, %4", ret, oldval, tmp, uaddr, oparg);
>  		break;
> +#endif
>  	default:
>  		ret = -ENOSYS;
>  	}
> 
> and the below proves it:
> 
> diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
> index e133da303a98..a9151884bc85 100644
> --- a/arch/arm/include/asm/futex.h
> +++ b/arch/arm/include/asm/futex.h
> @@ -165,8 +165,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
>  	preempt_enable();
>  #endif
>  
> -	if (!ret)
> -		*oval = oldval;
> +	/*
> +	 * Store unconditionally. If ret != 0 the extra store is the least
> +	 * of the worries but GCC cannot figure out that __futex_atomic_op()
> +	 * is either setting ret to -EFAULT or storing the old value in
> +	 * oldval which results in a uninitialized warning at the call site.
> +	 */
> +	*oval = oldval;
>  
>  	return ret;
>  }
> 
> I think that's the right thing to do anyway. The conditional is pointless.

Thanks for the analysis.

I am still getting this warning, now from Linus' tree builds.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-04-01 22:00     ` Stephen Rothwell
@ 2020-04-01 22:39       ` Thomas Gleixner
  2020-04-13  0:01         ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Thomas Gleixner @ 2020-04-01 22:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, Al Viro

Stephen,

Stephen Rothwell <sfr@canb.auug.org.au> writes:
> On Wed, 01 Apr 2020 12:25:25 +0200 Thomas Gleixner <tglx@linutronix.de> wrote:
>> Me neither. Which compiler version?
>
> arm-linux-gnueabi-gcc (Debian 9.2.1-21) 9.2.1 20191130
>
>> I'm using arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0 which does not
>> show that oddity.
>
> I assume it is because of the change to arch_futex_atomic_op_inuser()
> for arm and the compiler is not clever enough to work out that the early
> return from arch_futex_atomic_op_inuser() means that oldval is not
> referenced in its caller.

Actually no. It's the ASM part which causes this. With the following
hack applied it compiles:

diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index e133da303a98..2c6b40f71009 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -132,7 +132,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 static inline int
 arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
 {
-	int oldval = 0, ret, tmp;
+	int oldval = 0, ret;
 
 	if (!access_ok(uaddr, sizeof(u32)))
 		return -EFAULT;
@@ -142,6 +142,7 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
 #endif
 
 	switch (op) {
+#if 0
 	case FUTEX_OP_SET:
 		__futex_atomic_op("mov	%0, %4", ret, oldval, tmp, uaddr, oparg);
 		break;
@@ -157,6 +158,7 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
 	case FUTEX_OP_XOR:
 		__futex_atomic_op("eor	%0, %1, %4", ret, oldval, tmp, uaddr, oparg);
 		break;
+#endif
 	default:
 		ret = -ENOSYS;
 	}

but with this is emits the warning:

diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index e133da303a98..5191d7b61b83 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -145,6 +145,7 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
 	case FUTEX_OP_SET:
 		__futex_atomic_op("mov	%0, %4", ret, oldval, tmp, uaddr, oparg);
 		break;
+#if 0
 	case FUTEX_OP_ADD:
 		__futex_atomic_op("add	%0, %1, %4", ret, oldval, tmp, uaddr, oparg);
 		break;
@@ -157,6 +158,7 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
 	case FUTEX_OP_XOR:
 		__futex_atomic_op("eor	%0, %1, %4", ret, oldval, tmp, uaddr, oparg);
 		break;
+#endif
 	default:
 		ret = -ENOSYS;
 	}

and the below proves it:

diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index e133da303a98..a9151884bc85 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -165,8 +165,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
 	preempt_enable();
 #endif
 
-	if (!ret)
-		*oval = oldval;
+	/*
+	 * Store unconditionally. If ret != 0 the extra store is the least
+	 * of the worries but GCC cannot figure out that __futex_atomic_op()
+	 * is either setting ret to -EFAULT or storing the old value in
+	 * oldval which results in a uninitialized warning at the call site.
+	 */
+	*oval = oldval;
 
 	return ret;
 }

I think that's the right thing to do anyway. The conditional is pointless.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-04-01 10:25   ` Thomas Gleixner
@ 2020-04-01 22:00     ` Stephen Rothwell
  2020-04-01 22:39       ` Thomas Gleixner
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2020-04-01 22:00 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, Al Viro


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

Hi Thomas,

On Wed, 01 Apr 2020 12:25:25 +0200 Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> >
> > On Mon, 30 Mar 2020 13:47:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> >>
> >> After merging the tip tree, today's linux-next build (arm
> >> multi_v7_defconfig) produced this warning:
> >> 
> >> kernel/futex.c: In function 'do_futex':
> >> kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
> >>  1676 |   return oldval == cmparg;
> >>       |          ~~~~~~~^~~~~~~~~
> >> kernel/futex.c:1652:6: note: 'oldval' was declared here
> >>  1652 |  int oldval, ret;
> >>       |      ^~~~~~
> >> 
> >> Introduced by commit
> >> 
> >>   a08971e9488d ("futex: arch_futex_atomic_op_inuser() calling
> >>   conventions change")  
> 
> Huch?
>  
> >> but I don't arm-linux-gnueabi-gcc (Debian 9.2.1-21) 9.2.1 20191130see how it makes this difference :-(  
> 
> Me neither. Which compiler version?

arm-linux-gnueabi-gcc (Debian 9.2.1-21) 9.2.1 20191130

> I'm using arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0 which does not
> show that oddity.

I assume it is because of the change to arch_futex_atomic_op_inuser()
for arm and the compiler is not clever enough to work out that the early
return from arch_futex_atomic_op_inuser() means that oldval is not
referenced in its caller.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-03-31 21:57 ` Stephen Rothwell
@ 2020-04-01 10:25   ` Thomas Gleixner
  2020-04-01 22:00     ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Thomas Gleixner @ 2020-04-01 10:25 UTC (permalink / raw)
  To: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Al Viro

Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> On Mon, 30 Mar 2020 13:47:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>> 
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) produced this warning:
>> 
>> kernel/futex.c: In function 'do_futex':
>> kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
>>  1676 |   return oldval == cmparg;
>>       |          ~~~~~~~^~~~~~~~~
>> kernel/futex.c:1652:6: note: 'oldval' was declared here
>>  1652 |  int oldval, ret;
>>       |      ^~~~~~
>> 
>> Introduced by commit
>> 
>>   a08971e9488d ("futex: arch_futex_atomic_op_inuser() calling
>>   conventions change")

Huch?
 
>> but I don't see how it makes this difference :-(

Me neither. Which compiler version?

I'm using arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0 which does not
show that oddity.

Thanks,

        tglx


^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-03-30  2:47 Stephen Rothwell
@ 2020-03-31 21:57 ` Stephen Rothwell
  2020-04-01 10:25   ` Thomas Gleixner
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2020-03-31 21:57 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Al Viro


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

Hi all,

On Mon, 30 Mar 2020 13:47:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> kernel/futex.c: In function 'do_futex':
> kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
>  1676 |   return oldval == cmparg;
>       |          ~~~~~~~^~~~~~~~~
> kernel/futex.c:1652:6: note: 'oldval' was declared here
>  1652 |  int oldval, ret;
>       |      ^~~~~~
> 
> Introduced by commit
> 
>   a08971e9488d ("futex: arch_futex_atomic_op_inuser() calling conventions change")
> 
> but I don't see how it makes this difference :-(

I now get this warning from building Linus' tree :-(

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2020-03-30  2:47 Stephen Rothwell
  2020-03-31 21:57 ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2020-03-30  2:47 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Al Viro


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

Hi all,

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

kernel/futex.c: In function 'do_futex':
kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
 1676 |   return oldval == cmparg;
      |          ~~~~~~~^~~~~~~~~
kernel/futex.c:1652:6: note: 'oldval' was declared here
 1652 |  int oldval, ret;
      |      ^~~~~~

Introduced by commit

  a08971e9488d ("futex: arch_futex_atomic_op_inuser() calling conventions change")

but I don't see how it makes this difference :-(

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-01-20  5:38 Stephen Rothwell
@ 2020-01-20  6:00 ` Viresh Kumar
  0 siblings, 0 replies; 113+ messages in thread
From: Viresh Kumar @ 2020-01-20  6:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

On 20-01-20, 16:38, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allnoconfig
> and a couple of other allnoconfigs) produced this warning:
> 
> kernel/sched/fair.c:5221:12: warning: 'sched_idle_cpu' defined but not used [-Wunused-function]
>  5221 | static int sched_idle_cpu(int cpu)
>       |            ^~~~~~~~~~~~~~
> 
> Introduced (I think) by commit
> 
>   323af6deaf70 ("sched/fair: Load balance aggressively for SCHED_IDLE CPUs")

Thanks for reporting this Stephen.

I have sent a fix for it now and cc'd you as well.

-- 
viresh

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2020-01-20  5:38 Stephen Rothwell
  2020-01-20  6:00 ` Viresh Kumar
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2020-01-20  5:38 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Viresh Kumar


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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allnoconfig
and a couple of other allnoconfigs) produced this warning:

kernel/sched/fair.c:5221:12: warning: 'sched_idle_cpu' defined but not used [-Wunused-function]
 5221 | static int sched_idle_cpu(int cpu)
      |            ^~~~~~~~~~~~~~

Introduced (I think) by commit

  323af6deaf70 ("sched/fair: Load balance aggressively for SCHED_IDLE CPUs")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-01-07  7:16 ` Ingo Molnar
@ 2020-01-07  7:22   ` Shile Zhang
  0 siblings, 0 replies; 113+ messages in thread
From: Shile Zhang @ 2020-01-07  7:22 UTC (permalink / raw)
  To: Ingo Molnar, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List



On 2020/1/7 15:16, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> [This has been happening for a while, I just missed it :-( ]
>>
>> After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
>> produced this warning:
>>
>> arch/x86/kernel/unwind_orc.c:210:12: warning: 'orc_sort_cmp' defined but not used [-Wunused-function]
>>    210 | static int orc_sort_cmp(const void *_a, const void *_b)
>>        |            ^~~~~~~~~~~~
>> arch/x86/kernel/unwind_orc.c:190:13: warning: 'orc_sort_swap' defined but not used [-Wunused-function]
>>    190 | static void orc_sort_swap(void *_a, void *_b, int size)
>>        |             ^~~~~~~~~~~~~
>>
>> Introduced by commit
>>
>>    f14bf6a350df ("x86/unwind/orc: Remove boot-time ORC unwind tables sorting")
> Now fixed via:
>
>    22a7fa8848c5: ("x86/unwind/orc: Fix !CONFIG_MODULES build warning")
>
> Will push it out after some testing, should go out with the next
> tip:auto-latest version.
Thanks very much! sorry for trouble.
>
> Thanks,
>
> 	Ingo


^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2020-01-07  5:43 Stephen Rothwell
@ 2020-01-07  7:16 ` Ingo Molnar
  2020-01-07  7:22   ` Shile Zhang
  0 siblings, 1 reply; 113+ messages in thread
From: Ingo Molnar @ 2020-01-07  7:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List, Shile Zhang


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> [This has been happening for a while, I just missed it :-( ]
> 
> After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
> produced this warning:
> 
> arch/x86/kernel/unwind_orc.c:210:12: warning: 'orc_sort_cmp' defined but not used [-Wunused-function]
>   210 | static int orc_sort_cmp(const void *_a, const void *_b)
>       |            ^~~~~~~~~~~~
> arch/x86/kernel/unwind_orc.c:190:13: warning: 'orc_sort_swap' defined but not used [-Wunused-function]
>   190 | static void orc_sort_swap(void *_a, void *_b, int size)
>       |             ^~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   f14bf6a350df ("x86/unwind/orc: Remove boot-time ORC unwind tables sorting")

Now fixed via:

  22a7fa8848c5: ("x86/unwind/orc: Fix !CONFIG_MODULES build warning")

Will push it out after some testing, should go out with the next 
tip:auto-latest version.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2020-01-07  5:43 Stephen Rothwell
  2020-01-07  7:16 ` Ingo Molnar
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2020-01-07  5:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Shile Zhang


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

Hi all,

[This has been happening for a while, I just missed it :-( ]

After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:

arch/x86/kernel/unwind_orc.c:210:12: warning: 'orc_sort_cmp' defined but not used [-Wunused-function]
  210 | static int orc_sort_cmp(const void *_a, const void *_b)
      |            ^~~~~~~~~~~~
arch/x86/kernel/unwind_orc.c:190:13: warning: 'orc_sort_swap' defined but not used [-Wunused-function]
  190 | static void orc_sort_swap(void *_a, void *_b, int size)
      |             ^~~~~~~~~~~~~

Introduced by commit

  f14bf6a350df ("x86/unwind/orc: Remove boot-time ORC unwind tables sorting")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2019-07-26  4:49 ` Josh Poimboeuf
@ 2019-07-26  5:49   ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2019-07-26  5:49 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List


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

Hi Josh,

On Thu, 25 Jul 2019 23:49:09 -0500 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> This will be fixed by:
> 
>   https://lkml.kernel.org/r/51a4155c5bc2ca847a9cbe85c1c11918bb193141.1564086017.git.jpoimboe@redhat.com

Thanks

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2019-07-26  3:05 Stephen Rothwell
@ 2019-07-26  4:49 ` Josh Poimboeuf
  2019-07-26  5:49   ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Josh Poimboeuf @ 2019-07-26  4:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List

On Fri, Jul 26, 2019 at 01:05:49PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x1c: redundant UACCESS disable
> 
> Presuambly introduced/uncovered by commit
> 
>   882a0db9d143 ("objtool: Improve UACCESS coverage")

This will be fixed by:

  https://lkml.kernel.org/r/51a4155c5bc2ca847a9cbe85c1c11918bb193141.1564086017.git.jpoimboe@redhat.com

-- 
Josh

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2019-07-26  3:05 Stephen Rothwell
  2019-07-26  4:49 ` Josh Poimboeuf
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2019-07-26  3:05 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Josh Poimboeuf


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

Hi all,

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

drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x1c: redundant UACCESS disable

Presuambly introduced/uncovered by commit

  882a0db9d143 ("objtool: Improve UACCESS coverage")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2018-11-06  0:46 Stephen Rothwell
@ 2018-12-19  0:55 ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2018-12-19  0:55 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mark Rutland


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

Hi all,

On Tue, 6 Nov 2018 11:46:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> warning: include/asm-generic/atomic-instrumented.h is out-of-date.
> warning: include/asm-generic/atomic-long.h is out-of-date.
> warning: include/linux/atomic-fallback.h is out-of-date.
> 
> Exposed by commit
> 
>   8d32588077bd ("locking/atomics: Check generated headers are up-to-date")

I am still getting these.  Are they expected?  To be ignored?

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2018-11-06  0:46 Stephen Rothwell
  2018-12-19  0:55 ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2018-11-06  0:46 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mark Rutland


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

Hi all,

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

warning: include/asm-generic/atomic-instrumented.h is out-of-date.
warning: include/asm-generic/atomic-long.h is out-of-date.
warning: include/linux/atomic-fallback.h is out-of-date.

Exposed by commit

  8d32588077bd ("locking/atomics: Check generated headers are up-to-date")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2018-09-11  3:53 Stephen Rothwell
@ 2018-09-12 19:35 ` Thomas Gleixner
  0 siblings, 0 replies; 113+ messages in thread
From: Thomas Gleixner @ 2018-09-12 19:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Andy Lutomirski

On Tue, 11 Sep 2018, Stephen Rothwell wrote:
> After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
> produced this warning:
> 
> arch/x86/kernel/cpu/common.c: In function 'syscall_init':
> arch/x86/kernel/cpu/common.c:1534:6: warning: unused variable 'cpu' [-Wunused-variable]
>   int cpu = smp_processor_id();
>       ^~~
> 
> Introduced by commit
> 
>   86635715ee42 ("x86/pti/64: Remove the SYSCALL64 entry trampoline")

Hrmpf. My randconfigs seem not to be random enough. Fixed.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2018-09-11  3:53 Stephen Rothwell
  2018-09-12 19:35 ` Thomas Gleixner
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2018-09-11  3:53 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andy Lutomirski


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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:

arch/x86/kernel/cpu/common.c: In function 'syscall_init':
arch/x86/kernel/cpu/common.c:1534:6: warning: unused variable 'cpu' [-Wunused-variable]
  int cpu = smp_processor_id();
      ^~~

Introduced by commit

  86635715ee42 ("x86/pti/64: Remove the SYSCALL64 entry trampoline")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2018-03-23  8:31 ` Christoph Hellwig
@ 2018-03-23  9:57   ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2018-03-23  9:57 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List


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

Hi Christoph,

On Fri, 23 Mar 2018 09:31:34 +0100 Christoph Hellwig <hch@lst.de> wrote:
>
> True.  I'll send a fixup.

Thanks.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2018-03-23  2:28 Stephen Rothwell
@ 2018-03-23  8:31 ` Christoph Hellwig
  2018-03-23  9:57   ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Christoph Hellwig @ 2018-03-23  8:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig

On Fri, Mar 23, 2018 at 01:28:53PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> lib/swiotlb.c:748:13: warning: 'swiotlb_free_buffer' defined but not used [-Wunused-function]
>  static bool swiotlb_free_buffer(struct device *dev, size_t size,
>              ^~~~~~~~~~~~~~~~~~~
> lib/swiotlb.c:706:1: warning: 'swiotlb_alloc_buffer' defined but not used [-Wunused-function]
>  swiotlb_alloc_buffer(struct device *dev, size_t size, dma_addr_t *dma_handle,
>  ^~~~~~~~~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   16e73adbca76 ("dma/swiotlb: Remove swiotlb_{alloc,free}_coherent()")
> 
> These are now only used with CONFIG_DMA_DIRECT_OPS.

True.  I'll send a fixup.

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2018-03-23  2:28 Stephen Rothwell
  2018-03-23  8:31 ` Christoph Hellwig
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2018-03-23  2:28 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig


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

Hi all,

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

lib/swiotlb.c:748:13: warning: 'swiotlb_free_buffer' defined but not used [-Wunused-function]
 static bool swiotlb_free_buffer(struct device *dev, size_t size,
             ^~~~~~~~~~~~~~~~~~~
lib/swiotlb.c:706:1: warning: 'swiotlb_alloc_buffer' defined but not used [-Wunused-function]
 swiotlb_alloc_buffer(struct device *dev, size_t size, dma_addr_t *dma_handle,
 ^~~~~~~~~~~~~~~~~~~~

Introduced by commit

  16e73adbca76 ("dma/swiotlb: Remove swiotlb_{alloc,free}_coherent()")

These are now only used with CONFIG_DMA_DIRECT_OPS.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2018-03-16  5:37 Stephen Rothwell
  2018-03-16  5:52 ` Dou Liyang
@ 2018-03-16  7:55 ` Thomas Gleixner
  1 sibling, 0 replies; 113+ messages in thread
From: Thomas Gleixner @ 2018-03-16  7:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Lai Jiangshan

On Fri, 16 Mar 2018, Stephen Rothwell wrote:

> Hi all,
> 
> After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
> produced this warning:
> 
> kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used [-Wunused-function]
>  static bool cpuhp_is_ap_state(enum cpuhp_state state)
>              ^~~~~~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   17a2f1ced028 ("cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states")

Fix is queued already. Did not make it into the branch you pull yet.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2018-03-16  5:52 ` Dou Liyang
@ 2018-03-16  6:04   ` Dou Liyang
  0 siblings, 0 replies; 113+ messages in thread
From: Dou Liyang @ 2018-03-16  6:04 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Lai Jiangshan

Hi Stephen,

At 03/16/2018 01:52 PM, Dou Liyang wrote:
> Hi Stephen,
> 
> At 03/16/2018 01:37 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, yesterday's linux-next build (x86_64 
>> allnoconfig)
>> produced this warning:
>>
>> kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used 
>> [-Wunused-function]
>>   static bool cpuhp_is_ap_state(enum cpuhp_state state)
>>               ^~~~~~~~~~~~~~~~~
>>
> 
> Yes, Jiangshan has replaced it with cpuhp_hp_states. So it is obsolete,
> it should be removed.
> 

I made a mistake, It also be called by cpuhp_thread_fun() and
cpuhp_issue_call(), let me have a look carefully.

Thanks,
	dou.

> Thanks,
>      dou.
>> Introduced by commit
>>
>>    17a2f1ced028 ("cpu/hotplug: Merge cpuhp_bp_states and 
>> cpuhp_ap_states")
>>

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2018-03-16  5:37 Stephen Rothwell
@ 2018-03-16  5:52 ` Dou Liyang
  2018-03-16  6:04   ` Dou Liyang
  2018-03-16  7:55 ` Thomas Gleixner
  1 sibling, 1 reply; 113+ messages in thread
From: Dou Liyang @ 2018-03-16  5:52 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Lai Jiangshan

Hi Stephen,

At 03/16/2018 01:37 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
> produced this warning:
> 
> kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used [-Wunused-function]
>   static bool cpuhp_is_ap_state(enum cpuhp_state state)
>               ^~~~~~~~~~~~~~~~~
> 

Yes, Jiangshan has replaced it with cpuhp_hp_states. So it is obsolete,
it should be removed.

Thanks,
	dou.
> Introduced by commit
> 
>    17a2f1ced028 ("cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states")
> 

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2018-03-16  5:37 Stephen Rothwell
  2018-03-16  5:52 ` Dou Liyang
  2018-03-16  7:55 ` Thomas Gleixner
  0 siblings, 2 replies; 113+ messages in thread
From: Stephen Rothwell @ 2018-03-16  5:37 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Lai Jiangshan


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

Hi all,

After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
produced this warning:

kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used [-Wunused-function]
 static bool cpuhp_is_ap_state(enum cpuhp_state state)
             ^~~~~~~~~~~~~~~~~

Introduced by commit

  17a2f1ced028 ("cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2018-01-10  4:41 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2018-01-10  4:41 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Woodhouse

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:

arch/x86/kernel/cpu/bugs.c:79:12: warning: 'spectre_v2_enabled' defined but not used [-Wunused-variable]
 static int spectre_v2_enabled = SPECTRE_V2_NONE;
            ^

Introduced by commit

  54d5103245ff ("x86/spectre: Add boot time option to select Spectre v2 mitigation")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2017-09-27  3:42 Stephen Rothwell
@ 2017-09-27 11:50 ` Prarit Bhargava
  0 siblings, 0 replies; 113+ messages in thread
From: Prarit Bhargava @ 2017-09-27 11:50 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List



On 09/26/2017 11:42 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
> produced this warning:
> 
> kernel/printk/printk.c:1983:12: warning: 'printk_time' defined but not used [-Wunused-variable]
>  static int printk_time;
>             ^
> 
> Introduced by commit
> 
>   310b454a8653 ("printk: Add monotonic, boottime, and realtime timestamps")
> 

Fix sent upstream here:

https://marc.info/?l=linux-kernel&m=150644159607745&w=2

P.

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2017-09-27  3:42 Stephen Rothwell
  2017-09-27 11:50 ` Prarit Bhargava
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2017-09-27  3:42 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Prarit Bhargava

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:

kernel/printk/printk.c:1983:12: warning: 'printk_time' defined but not used [-Wunused-variable]
 static int printk_time;
            ^

Introduced by commit

  310b454a8653 ("printk: Add monotonic, boottime, and realtime timestamps")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2017-06-28  7:15 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2017-06-28  7:15 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Rik van Riel

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:

kernel/sched/fair.c:2657:9: warning: 'struct sched_domain' declared inside parameter list
         int prev_cpu, int sync)
         ^
/home/sfr/next/next/kernel/sched/fair.c:2657:9: warning: its scope is only this definition or declaration, which is probably not what you want

Introduced by commit

  3fed382b46ba ("sched/numa: Implement NUMA node level wake_affine()")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2017-06-23  4:10   ` Michael Ellerman
@ 2017-06-23  4:22     ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2017-06-23  4:22 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Benjamin Herrenschmidt, PowerPC, John Stultz

Hi Michael,

On Fri, 23 Jun 2017 14:10:25 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Fixed in my next today by:
> 
>   d4cfb11387ee ("powerpc: Convert VDSO update function to use new update_vsyscall interface")
> 
> But you must have pulled before I pushed that, so the warning will go
> away tomorrow.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2017-06-23  4:00 ` Stephen Rothwell
@ 2017-06-23  4:10   ` Michael Ellerman
  2017-06-23  4:22     ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Michael Ellerman @ 2017-06-23  4:10 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Benjamin Herrenschmidt, PowerPC, John Stultz

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi all,
>
> [Forgot to cc John]
>
> On Fri, 23 Jun 2017 13:58:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>> 
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced this warning:
>> 
>> kernel/time/timekeeping.c:519:2: warning: #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon. [-Wcpp]
>>  #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon.
>>   ^
>> kernel/time/timekeeping.c:519:2: warning: #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon. [-Wcpp]
>>  #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon.
>>   ^
>> 
>> Introduced by commit
>> 
>>   369adf04d80a ("time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD")

Fixed in my next today by:

  d4cfb11387ee ("powerpc: Convert VDSO update function to use new update_vsyscall interface")

But you must have pulled before I pushed that, so the warning will go
away tomorrow.

cheers

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2017-06-23  3:58 Stephen Rothwell
@ 2017-06-23  4:00 ` Stephen Rothwell
  2017-06-23  4:10   ` Michael Ellerman
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2017-06-23  4:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Michael Ellerman, Benjamin Herrenschmidt, PowerPC, John Stultz

Hi all,

[Forgot to cc John]

On Fri, 23 Jun 2017 13:58:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> kernel/time/timekeeping.c:519:2: warning: #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon. [-Wcpp]
>  #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon.
>   ^
> kernel/time/timekeeping.c:519:2: warning: #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon. [-Wcpp]
>  #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon.
>   ^
> 
> Introduced by commit
> 
>   369adf04d80a ("time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2017-06-23  3:58 Stephen Rothwell
  2017-06-23  4:00 ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2017-06-23  3:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Michael Ellerman, Benjamin Herrenschmidt, PowerPC

Hi all,

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

kernel/time/timekeeping.c:519:2: warning: #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon. [-Wcpp]
 #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon.
  ^
kernel/time/timekeeping.c:519:2: warning: #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon. [-Wcpp]
 #warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD compatibity will disappear soon.
  ^

Introduced by commit

  369adf04d80a ("time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-12-14  8:05   ` Richard Weinberger
@ 2016-12-14  8:26     ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2016-12-14  8:26 UTC (permalink / raw)
  To: Richard Weinberger
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Artem Bityutskiy, linux-next, linux-kernel,
	David Gstir

Hi Richard,

On Wed, 14 Dec 2016 09:05:10 +0100 Richard Weinberger <richard@nod.at> wrote:
>
> The commit comes via my UBIFS tree. But I never saw this warning, I'm testing with both gcc-4.8 and gcc-6.1.
> Let me investigate into that.
> 
> Does today's tip change some compiler flags?

Linus' tree commit

  a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"")

was introduced between -rc4 and -rc5 so it is not in your tree.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-12-14  7:24 ` Ingo Molnar
  2016-12-14  8:05   ` Richard Weinberger
@ 2016-12-14  8:10   ` Stephen Rothwell
  1 sibling, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2016-12-14  8:10 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Artem Bityutskiy, linux-next, linux-kernel, Richard Weinberger

Hi Ingo,

On Wed, 14 Dec 2016 08:24:11 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> FYI, f4f61d2cc6d8 is not in the -tip tree, so it cannot possibly have introduced 
> this warning.

Yeah, I know, but the warning only seemed to happen after merging the
tip tree.  I would have expected it to appear much earlier like when I
merged the ubifs tree.  I figured that out, but forgot to mention it,
sorry.

Actually I just checked and it did turn up then, but my heuristics did
not point it out :-(
-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-12-14  7:24 ` Ingo Molnar
@ 2016-12-14  8:05   ` Richard Weinberger
  2016-12-14  8:26     ` Stephen Rothwell
  2016-12-14  8:10   ` Stephen Rothwell
  1 sibling, 1 reply; 113+ messages in thread
From: Richard Weinberger @ 2016-12-14  8:05 UTC (permalink / raw)
  To: Ingo Molnar, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Artem Bityutskiy, linux-next, linux-kernel, David Gstir

Stephen, Ingo,

CC'ing David.

On 14.12.2016 08:24, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> produced this warning:
>>
>> fs/ubifs/dir.c: In function 'ubifs_readdir':
>> fs/ubifs/dir.c:629:13: warning: 'fstr_real_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
>>     fstr.len = fstr_real_len;
>>              ^
>>
>> Introduced by commit
>>
>>   f4f61d2cc6d8 ("ubifs: Implement encrypted filenames")
>>
>> This is a false positive because assignment and use are both protected by
>> "if (encrypted)".
>>
>> I have no idea why this did not turn up earlier in my builds.
> 
> FYI, f4f61d2cc6d8 is not in the -tip tree, so it cannot possibly have introduced 
> this warning.

The commit comes via my UBIFS tree. But I never saw this warning, I'm testing with both gcc-4.8 and gcc-6.1.
Let me investigate into that.

Does today's tip change some compiler flags?

Thanks,
//richard

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-12-14  2:28 Stephen Rothwell
@ 2016-12-14  7:24 ` Ingo Molnar
  2016-12-14  8:05   ` Richard Weinberger
  2016-12-14  8:10   ` Stephen Rothwell
  0 siblings, 2 replies; 113+ messages in thread
From: Ingo Molnar @ 2016-12-14  7:24 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Artem Bityutskiy, linux-next, linux-kernel, Richard Weinberger


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> fs/ubifs/dir.c: In function 'ubifs_readdir':
> fs/ubifs/dir.c:629:13: warning: 'fstr_real_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
>     fstr.len = fstr_real_len;
>              ^
> 
> Introduced by commit
> 
>   f4f61d2cc6d8 ("ubifs: Implement encrypted filenames")
> 
> This is a false positive because assignment and use are both protected by
> "if (encrypted)".
> 
> I have no idea why this did not turn up earlier in my builds.

FYI, f4f61d2cc6d8 is not in the -tip tree, so it cannot possibly have introduced 
this warning.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2016-12-14  2:28 Stephen Rothwell
  2016-12-14  7:24 ` Ingo Molnar
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2016-12-14  2:28 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Artem Bityutskiy
  Cc: linux-next, linux-kernel, Richard Weinberger

Hi all,

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

fs/ubifs/dir.c: In function 'ubifs_readdir':
fs/ubifs/dir.c:629:13: warning: 'fstr_real_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
    fstr.len = fstr_real_len;
             ^

Introduced by commit

  f4f61d2cc6d8 ("ubifs: Implement encrypted filenames")

This is a false positive because assignment and use are both protected by
"if (encrypted)".

I have no idea why this did not turn up earlier in my builds.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-07-25 16:42       ` Mark Brown
@ 2016-07-25 17:54         ` Rich Felker
  0 siblings, 0 replies; 113+ messages in thread
From: Rich Felker @ 2016-07-25 17:54 UTC (permalink / raw)
  To: Mark Brown
  Cc: Daniel Lezcano, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Marc Zyngier

On Mon, Jul 25, 2016 at 05:42:09PM +0100, Mark Brown wrote:
> On Mon, Jul 25, 2016 at 10:53:37AM -0400, Rich Felker wrote:
> > On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:
> 
> > > I don't know the goal of adding those patches in linux-next via your
> > > tree, may be you misunderstood how linux-next works and you should
> > > remove them. But if the purpose was to merge the patches, I remind you
> > > that being an arch maintainer does not give you the right to apply any
> > > patches, everywhere, at all cost, without review, because you want them
> > > in, you must follow the process, otherwise you take the risk to upset a
> > > lot of people and to be kicked out.
> 
> > If this is upsetting people I can remove them. Last time I got
> > feedback from at least one (driver) subsystem maintainer that (if I
> > understood it correctly) indicated they would like to have seen the
> > patch in linux-next without problems before upstreaming it through
> 
> I think that was me and you've very much misunderstood what I was
> saying.  A that time you were sending new drivers during the merge
> window with the apparent expectation that they would be merged during
> that merge window.  That's not going to happen, things need to go into
> -next before the merge window.  This means that you need to submit your
> patches well in advance of the merge window so they can be reviewed and
> ideally applied to maintainer trees before the merge window opens.
> 
> It does not mean that you should include unreviewed code for other trees
> in your -next tree, that's not the purpose of -next.  What goes into
> -next from each maintainer tree should be what is currently intended to
> go to Linus for that tree in the next merge window.

OK, thanks for the clarification. I'll remove the drivers from my
for-next branch.

Rich

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-07-25 14:53     ` Rich Felker
@ 2016-07-25 16:42       ` Mark Brown
  2016-07-25 17:54         ` Rich Felker
  0 siblings, 1 reply; 113+ messages in thread
From: Mark Brown @ 2016-07-25 16:42 UTC (permalink / raw)
  To: Rich Felker
  Cc: Daniel Lezcano, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Marc Zyngier


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

On Mon, Jul 25, 2016 at 10:53:37AM -0400, Rich Felker wrote:
> On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:

> > I don't know the goal of adding those patches in linux-next via your
> > tree, may be you misunderstood how linux-next works and you should
> > remove them. But if the purpose was to merge the patches, I remind you
> > that being an arch maintainer does not give you the right to apply any
> > patches, everywhere, at all cost, without review, because you want them
> > in, you must follow the process, otherwise you take the risk to upset a
> > lot of people and to be kicked out.

> If this is upsetting people I can remove them. Last time I got
> feedback from at least one (driver) subsystem maintainer that (if I
> understood it correctly) indicated they would like to have seen the
> patch in linux-next without problems before upstreaming it through

I think that was me and you've very much misunderstood what I was
saying.  A that time you were sending new drivers during the merge
window with the apparent expectation that they would be merged during
that merge window.  That's not going to happen, things need to go into
-next before the merge window.  This means that you need to submit your
patches well in advance of the merge window so they can be reviewed and
ideally applied to maintainer trees before the merge window opens.

It does not mean that you should include unreviewed code for other trees
in your -next tree, that's not the purpose of -next.  What goes into
-next from each maintainer tree should be what is currently intended to
go to Linus for that tree in the next merge window.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-07-25 13:11   ` Daniel Lezcano
@ 2016-07-25 14:53     ` Rich Felker
  2016-07-25 16:42       ` Mark Brown
  0 siblings, 1 reply; 113+ messages in thread
From: Rich Felker @ 2016-07-25 14:53 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Mark Brown,
	Marc Zyngier

On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:
> On 07/25/2016 09:16 AM, Thomas Gleixner wrote:
> > On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> >> produced this warning:
> >>
> >> In file included from include/linux/clocksource.h:18:0,
> >>                  from include/linux/clockchips.h:13,
> >>                  from drivers/clocksource/jcore-pit.c:14:
> >> include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
> >>         .data = (fn == (fn_type)NULL) ? fn : fn  }
> >>                     ^
> >> include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
> >>    _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
> >>    ^
> >> include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
> >>   OF_DECLARE_1_RET(clksrc, name, compat, fn)
> >>   ^
> >> drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
> >>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> >>  ^
> >>
> >> Introduced by commits
> >>
> >>   b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
> >>   177cf6e52b0a ("clocksources: Switch back to the clksrc table")
> >>
> >> interacting with commit
> >>
> >>   e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> >>
> >> from the sh tree.
> > 
> > And why is that driver coming through the superh tree and not through the
> > clocksource maintainers? It's not only based on an old interface it's probably
> > unreviewed as well ...
> 
> Rich,
> 
> why are these changes in linux-next ?
> 
> Except I am missing something, I don't see a new version sent for review
> on the mailing list. The interrupt controller driver is almost empty as
> stated by Marc Zyngier and there is no explanation / discussion about it.
> 
> I don't know the goal of adding those patches in linux-next via your
> tree, may be you misunderstood how linux-next works and you should
> remove them. But if the purpose was to merge the patches, I remind you
> that being an arch maintainer does not give you the right to apply any
> patches, everywhere, at all cost, without review, because you want them
> in, you must follow the process, otherwise you take the risk to upset a
> lot of people and to be kicked out.

If this is upsetting people I can remove them. Last time I got
feedback from at least one (driver) subsystem maintainer that (if I
understood it correctly) indicated they would like to have seen the
patch in linux-next without problems before upstreaming it through
their tree. That was my motivation for including it here. I'm not
trying to bypass other maintainers to push patches upstream and I can
remove all non-arch/sh stuff from for-next if that would be better.

Rich

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-07-25  7:16 ` Thomas Gleixner
  2016-07-25 13:11   ` Daniel Lezcano
@ 2016-07-25 14:48   ` Rich Felker
  1 sibling, 0 replies; 113+ messages in thread
From: Rich Felker @ 2016-07-25 14:48 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Daniel Lezcano

On Mon, Jul 25, 2016 at 09:16:48AM +0200, Thomas Gleixner wrote:
> On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> > 
> > In file included from include/linux/clocksource.h:18:0,
> >                  from include/linux/clockchips.h:13,
> >                  from drivers/clocksource/jcore-pit.c:14:
> > include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
> >         .data = (fn == (fn_type)NULL) ? fn : fn  }
> >                     ^
> > include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
> >    _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
> >    ^
> > include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
> >   OF_DECLARE_1_RET(clksrc, name, compat, fn)
> >   ^
> > drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
> >  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> >  ^
> > 
> > Introduced by commits
> > 
> >   b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
> >   177cf6e52b0a ("clocksources: Switch back to the clksrc table")
> > 
> > interacting with commit
> > 
> >   e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> > 
> > from the sh tree.
> 
> And why is that driver coming through the superh tree and not through the
> clocksource maintainers? It's not only based on an old interface it's probably
> unreviewed as well ...

Drivers will go upstream through their proper subsystem maintainers,
not from my tree, but last time I got feedback that these drivers had
not seen any testing in linux-next. I can refrain from including
patches that I can't upstream directly in my for-next branch in the
future if you'd prefer but this way seemed to make less work for
others.

Rich

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-07-25  7:16 ` Thomas Gleixner
@ 2016-07-25 13:11   ` Daniel Lezcano
  2016-07-25 14:53     ` Rich Felker
  2016-07-25 14:48   ` Rich Felker
  1 sibling, 1 reply; 113+ messages in thread
From: Daniel Lezcano @ 2016-07-25 13:11 UTC (permalink / raw)
  To: Stephen Rothwell, Rich Felker
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Mark Brown, Marc Zyngier

On 07/25/2016 09:16 AM, Thomas Gleixner wrote:
> On Sun, 24 Jul 2016, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> produced this warning:
>>
>> In file included from include/linux/clocksource.h:18:0,
>>                  from include/linux/clockchips.h:13,
>>                  from drivers/clocksource/jcore-pit.c:14:
>> include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
>>         .data = (fn == (fn_type)NULL) ? fn : fn  }
>>                     ^
>> include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
>>    _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
>>    ^
>> include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
>>   OF_DECLARE_1_RET(clksrc, name, compat, fn)
>>   ^
>> drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
>>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
>>  ^
>>
>> Introduced by commits
>>
>>   b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
>>   177cf6e52b0a ("clocksources: Switch back to the clksrc table")
>>
>> interacting with commit
>>
>>   e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
>>
>> from the sh tree.
> 
> And why is that driver coming through the superh tree and not through the
> clocksource maintainers? It's not only based on an old interface it's probably
> unreviewed as well ...

Rich,

why are these changes in linux-next ?

Except I am missing something, I don't see a new version sent for review
on the mailing list. The interrupt controller driver is almost empty as
stated by Marc Zyngier and there is no explanation / discussion about it.

I don't know the goal of adding those patches in linux-next via your
tree, may be you misunderstood how linux-next works and you should
remove them. But if the purpose was to merge the patches, I remind you
that being an arch maintainer does not give you the right to apply any
patches, everywhere, at all cost, without review, because you want them
in, you must follow the process, otherwise you take the risk to upset a
lot of people and to be kicked out.

 -- Daniel




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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-07-24  5:32 Stephen Rothwell
@ 2016-07-25  7:16 ` Thomas Gleixner
  2016-07-25 13:11   ` Daniel Lezcano
  2016-07-25 14:48   ` Rich Felker
  0 siblings, 2 replies; 113+ messages in thread
From: Thomas Gleixner @ 2016-07-25  7:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Rich Felker,
	linux-next, linux-kernel, Daniel Lezcano

On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> In file included from include/linux/clocksource.h:18:0,
>                  from include/linux/clockchips.h:13,
>                  from drivers/clocksource/jcore-pit.c:14:
> include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
>         .data = (fn == (fn_type)NULL) ? fn : fn  }
>                     ^
> include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
>    _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
>    ^
> include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
>   OF_DECLARE_1_RET(clksrc, name, compat, fn)
>   ^
> drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
>  ^
> 
> Introduced by commits
> 
>   b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
>   177cf6e52b0a ("clocksources: Switch back to the clksrc table")
> 
> interacting with commit
> 
>   e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> 
> from the sh tree.

And why is that driver coming through the superh tree and not through the
clocksource maintainers? It's not only based on an old interface it's probably
unreviewed as well ...

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2016-07-24  5:32 Stephen Rothwell
  2016-07-25  7:16 ` Thomas Gleixner
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2016-07-24  5:32 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rich Felker
  Cc: linux-next, linux-kernel, Daniel Lezcano

Hi all,

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

In file included from include/linux/clocksource.h:18:0,
                 from include/linux/clockchips.h:13,
                 from drivers/clocksource/jcore-pit.c:14:
include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
        .data = (fn == (fn_type)NULL) ? fn : fn  }
                    ^
include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
   _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
   ^
include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
  OF_DECLARE_1_RET(clksrc, name, compat, fn)
  ^
drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
 CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
 ^

Introduced by commits

  b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
  177cf6e52b0a ("clocksources: Switch back to the clksrc table")

interacting with commit

  e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")

from the sh tree.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-04-07  8:48 ` Ingo Molnar
@ 2016-04-07 12:03   ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2016-04-07 12:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

Hi Ingo,

On Thu, 7 Apr 2016 10:48:33 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> Indeed - and this only triggers on HAVE_GENERIC_RCU_GUP.
> 
> I've amended the commit.

Thanks.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2016-04-07  5:26 Stephen Rothwell
@ 2016-04-07  8:48 ` Ingo Molnar
  2016-04-07 12:03   ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Ingo Molnar @ 2016-04-07  8:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc ppc44x_defconfig)
> produced this warning:
> 
> mm/gup.c: In function 'get_user_pages_fast':
> mm/gup.c:1510:20: warning: unused variable 'mm' [-Wunused-variable]
>   struct mm_struct *mm = current->mm;
>                     ^
> 
> Introduced by commit
> 
>   dc8cfd957d85 ("mm/gup: Remove the macro overload API migration helpers from the get_user*() APIs")

Indeed - and this only triggers on HAVE_GENERIC_RCU_GUP.

I've amended the commit.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2016-04-07  5:26 Stephen Rothwell
  2016-04-07  8:48 ` Ingo Molnar
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2016-04-07  5:26 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel

Hi all,

After merging the tip tree, today's linux-next build (powerpc ppc44x_defconfig)
produced this warning:

mm/gup.c: In function 'get_user_pages_fast':
mm/gup.c:1510:20: warning: unused variable 'mm' [-Wunused-variable]
  struct mm_struct *mm = current->mm;
                    ^

Introduced by commit

  dc8cfd957d85 ("mm/gup: Remove the macro overload API migration helpers from the get_user*() APIs")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2015-05-12  3:35 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2015-05-12  3:35 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel


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

Hi all,

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

sound/drivers/pcsp/pcsp.c: In function 'snd_pcsp_create':
sound/drivers/pcsp/pcsp.c:51:5: warning: format '%li' expects argument of type 'long int', but argument 2 has type 'unsigned int' [-Wformat=]
     "(%linS)\n", resolution);
     ^

Introduced by commit 447fbbdc2cd5 ("sound: Use hrtimer_resolution
instead of hrtimer_get_res()").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2014-08-05  0:58 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2014-08-05  0:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, NeilBrown


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

Hi all,

After merging the tip tree, the linux-next build (x86_64 allmodconfig)
for some time has produced this warning:

fs/cifs/misc.c:578:1: warning: 'cifs_oplock_break_wait' defined but not used [-Wunused-function]
 cifs_oplock_break_wait(void *unused)
 ^

Introduced by commit 743162013d40 ("sched: Remove proliferation of
wait_on_bit() action functions").  This commit is now in Linus' tree -
sorry for not noticing earlier.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-07-18 20:20           ` Andy Lutomirski
@ 2014-07-18 20:50             ` H. Peter Anvin
  0 siblings, 0 replies; 113+ messages in thread
From: H. Peter Anvin @ 2014-07-18 20:50 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus Torvalds

On 07/18/2014 01:20 PM, Andy Lutomirski wrote:
>>
>> The reason this is a concern is that: (x > x + n) and its variants is
>> often used to mean (x > INT_MAX - n) without the type knowledge, but
>> that is actually invalid standard C because signed types are not
>> guaranteed to wrap.
> 
> Right, but the constant in this case is *much* less than INT_MAX.
> Anyway, this is moot.

It isn't about the constant (n) at all, it is about the value of x.

> I do wonder whether the kind of people who build hardened kernels
> should enable -fwrapv, though.

-fwrapv in gcc makes signed arithmetic strict 2's-complement, which is
what I think we want in the kernel.  Someone would just have to make
sure there isn't some key codepath in the kernel which gets pessimized.

	-hpa

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-07-18 20:15         ` H. Peter Anvin
@ 2014-07-18 20:20           ` Andy Lutomirski
  2014-07-18 20:50             ` H. Peter Anvin
  0 siblings, 1 reply; 113+ messages in thread
From: Andy Lutomirski @ 2014-07-18 20:20 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus Torvalds

On Fri, Jul 18, 2014 at 1:15 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 07/18/2014 01:08 PM, Andy Lutomirski wrote:
>>
>> i isn't an index in to the syms array at all.  This code is completely
>> wrong.  See the patch I sent in reply to Stephen's original email.
>>
>> But, to your earlier point, presumably this could warn:
>>
>> for (int i = 0; i < 10; i++)
>>   if (array[i] > array[5] + 1)
>>     fail();
>>
>> I think that's absurd.  There's nothing wrong with that code.  A given
>> test should have to be always true or always false on *all* loop
>> iterations to be flagged, I think.
>>
>
> No, the issue is that gcc is telling you that the code will do the wrong
> thing in this case.  Yes, only for one iteration, but still.
>
> The reason this is a concern is that: (x > x + n) and its variants is
> often used to mean (x > INT_MAX - n) without the type knowledge, but
> that is actually invalid standard C because signed types are not
> guaranteed to wrap.

Right, but the constant in this case is *much* less than INT_MAX.
Anyway, this is moot.

I do wonder whether the kind of people who build hardened kernels
should enable -fwrapv, though.

--Andy

>
>         -hpa
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-07-18 20:08       ` Andy Lutomirski
@ 2014-07-18 20:15         ` H. Peter Anvin
  2014-07-18 20:20           ` Andy Lutomirski
  0 siblings, 1 reply; 113+ messages in thread
From: H. Peter Anvin @ 2014-07-18 20:15 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus Torvalds

On 07/18/2014 01:08 PM, Andy Lutomirski wrote:
> 
> i isn't an index in to the syms array at all.  This code is completely
> wrong.  See the patch I sent in reply to Stephen's original email.
> 
> But, to your earlier point, presumably this could warn:
> 
> for (int i = 0; i < 10; i++)
>   if (array[i] > array[5] + 1)
>     fail();
> 
> I think that's absurd.  There's nothing wrong with that code.  A given
> test should have to be always true or always false on *all* loop
> iterations to be flagged, I think.
> 

No, the issue is that gcc is telling you that the code will do the wrong
thing in this case.  Yes, only for one iteration, but still.

The reason this is a concern is that: (x > x + n) and its variants is
often used to mean (x > INT_MAX - n) without the type knowledge, but
that is actually invalid standard C because signed types are not
guaranteed to wrap.

	-hpa

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-07-18 20:05     ` H. Peter Anvin
@ 2014-07-18 20:08       ` Andy Lutomirski
  2014-07-18 20:15         ` H. Peter Anvin
  0 siblings, 1 reply; 113+ messages in thread
From: Andy Lutomirski @ 2014-07-18 20:08 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus Torvalds

On Fri, Jul 18, 2014 at 1:05 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 07/18/2014 12:57 PM, Andy Lutomirski wrote:
>>
>> This particular warning is IMO in a particularly dumb category: GCC
>> optimizes some code and then warns about a construct that wasn't there
>> in the original code.  In this case, I think it unrolled a loop and
>> discovered that one iteration contained a test that was always true.
>> Big deal.
>>
>> (OTOH, the code in question was buggy, but not all for the reason that
>> GCC thought it was.)
>>
>
>                 if (syms[sym_vvar_start] > syms[i] + 4096)
>                         fail("%s underruns begin_vvar\n",
>                              required_syms[i].name);
>
> if i == sym_vvar_start then this is at least a valid warning.  It could
> easily be quieted by chaning syms[] to an unsigned array.

Hah -- fooled you, too :)

i isn't an index in to the syms array at all.  This code is completely
wrong.  See the patch I sent in reply to Stephen's original email.

But, to your earlier point, presumably this could warn:

for (int i = 0; i < 10; i++)
  if (array[i] > array[5] + 1)
    fail();

I think that's absurd.  There's nothing wrong with that code.  A given
test should have to be always true or always false on *all* loop
iterations to be flagged, I think.

--Andy

>
>         -hpa
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-07-18 19:57   ` Andy Lutomirski
@ 2014-07-18 20:05     ` H. Peter Anvin
  2014-07-18 20:08       ` Andy Lutomirski
  0 siblings, 1 reply; 113+ messages in thread
From: H. Peter Anvin @ 2014-07-18 20:05 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus Torvalds

On 07/18/2014 12:57 PM, Andy Lutomirski wrote:
> 
> This particular warning is IMO in a particularly dumb category: GCC
> optimizes some code and then warns about a construct that wasn't there
> in the original code.  In this case, I think it unrolled a loop and
> discovered that one iteration contained a test that was always true.
> Big deal.
> 
> (OTOH, the code in question was buggy, but not all for the reason that
> GCC thought it was.)
> 

		if (syms[sym_vvar_start] > syms[i] + 4096)
			fail("%s underruns begin_vvar\n",
			     required_syms[i].name);

if i == sym_vvar_start then this is at least a valid warning.  It could
easily be quieted by chaning syms[] to an unsigned array.

	-hpa

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-07-18 19:16 ` H. Peter Anvin
@ 2014-07-18 19:57   ` Andy Lutomirski
  2014-07-18 20:05     ` H. Peter Anvin
  0 siblings, 1 reply; 113+ messages in thread
From: Andy Lutomirski @ 2014-07-18 19:57 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, linux-kernel, Linus Torvalds

On Fri, Jul 18, 2014 at 12:16 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 07/17/2014 10:00 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64
>> allmodconfig) produced these warnings:
>>
>> In file included from arch/x86/vdso/vdso2c.c:161:0:
>> arch/x86/vdso/vdso2c.c: In function 'main':
>> arch/x86/vdso/vdso2c.h:118:6: warning: assuming signed overflow
>> does not occur when assuming that (X + c) < X is always false
>> [-Wstrict-overflow] In file included from
>> arch/x86/vdso/vdso2c.c:165:0: arch/x86/vdso/vdso2c.h:118:6:
>> warning: assuming signed overflow does not occur when assuming that
>> (X + c) < X is always false [-Wstrict-overflow]
>>
>> Probably introduced by commit e6577a7ce99a ("x86, vdso: Move the
>> vvar area before the vdso text").
>>
>
> This seems toxic.
>
> I always wonder if we shouldn't use -fwrapv for the kernel...

This particular warning is IMO in a particularly dumb category: GCC
optimizes some code and then warns about a construct that wasn't there
in the original code.  In this case, I think it unrolled a loop and
discovered that one iteration contained a test that was always true.
Big deal.

(OTOH, the code in question was buggy, but not all for the reason that
GCC thought it was.)

--Andy

>
>         -hpa
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-07-18  5:00 Stephen Rothwell
@ 2014-07-18 19:16 ` H. Peter Anvin
  2014-07-18 19:57   ` Andy Lutomirski
  0 siblings, 1 reply; 113+ messages in thread
From: H. Peter Anvin @ 2014-07-18 19:16 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andy Lutomirski, Linus Torvalds

On 07/17/2014 10:00 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
> 
> In file included from arch/x86/vdso/vdso2c.c:161:0: 
> arch/x86/vdso/vdso2c.c: In function 'main': 
> arch/x86/vdso/vdso2c.h:118:6: warning: assuming signed overflow
> does not occur when assuming that (X + c) < X is always false
> [-Wstrict-overflow] In file included from
> arch/x86/vdso/vdso2c.c:165:0: arch/x86/vdso/vdso2c.h:118:6:
> warning: assuming signed overflow does not occur when assuming that
> (X + c) < X is always false [-Wstrict-overflow]
> 
> Probably introduced by commit e6577a7ce99a ("x86, vdso: Move the
> vvar area before the vdso text").
> 

This seems toxic.

I always wonder if we shouldn't use -fwrapv for the kernel...

	-hpa

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2014-07-18  5:00 Stephen Rothwell
  2014-07-18 19:16 ` H. Peter Anvin
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2014-07-18  5:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andy Lutomirski


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

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from arch/x86/vdso/vdso2c.c:161:0:
arch/x86/vdso/vdso2c.c: In function 'main':
arch/x86/vdso/vdso2c.h:118:6: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
In file included from arch/x86/vdso/vdso2c.c:165:0:
arch/x86/vdso/vdso2c.h:118:6: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]

Probably introduced by commit e6577a7ce99a ("x86, vdso: Move the vvar
area before the vdso text").

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-06-20  4:30   ` H. Peter Anvin
@ 2014-06-20  4:35     ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2014-06-20  4:35 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, linux-next,
	linux-kernel, Fenghua Yu


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

Hi Peter,

On Thu, 19 Jun 2014 21:30:49 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 06/19/2014 09:24 PM, Stephen Rothwell wrote:
> > 
> > On Mon, 16 Jun 2014 11:57:09 +1000 Stephen Rothwell 
> > <sfr@canb.auug.org.au> wrote:
> >> 
> >> After merging the tip tree, today's linux-next build (x86_64 
> >> allmodconfig) produced this warning:
> >> 
> >> In file included from 
> >> arch/x86/crypto/camellia_aesni_avx_glue.c:23:0: 
> >> arch/x86/include/asm/xsave.h:73:12: warning: 
> >> 'xsave_state_booting' defined but not used [-Wunused-function] 
> >> static int xsave_state_booting(struct xsave_struct *fx, u64 mask)
> >> ^
> >> 
> >> Lots of these ...
> >> 
> >> Introduced by commit adb9d526e982 ("x86/xsaves: Add xsaves and 
> >> xrstors support for booting time").  Forgotten "inline" :-(
> > 
> > Ping?
> 
> I already applied an equivalent patch from Borislav.

Thanks.  I look forward to it filtering out :-)

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-06-20  4:24 ` Stephen Rothwell
@ 2014-06-20  4:30   ` H. Peter Anvin
  2014-06-20  4:35     ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: H. Peter Anvin @ 2014-06-20  4:30 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra
  Cc: linux-next, linux-kernel, Fenghua Yu

On 06/19/2014 09:24 PM, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 16 Jun 2014 11:57:09 +1000 Stephen Rothwell 
> <sfr@canb.auug.org.au> wrote:
>> 
>> After merging the tip tree, today's linux-next build (x86_64 
>> allmodconfig) produced this warning:
>> 
>> In file included from 
>> arch/x86/crypto/camellia_aesni_avx_glue.c:23:0: 
>> arch/x86/include/asm/xsave.h:73:12: warning: 
>> 'xsave_state_booting' defined but not used [-Wunused-function] 
>> static int xsave_state_booting(struct xsave_struct *fx, u64 mask)
>> ^
>> 
>> Lots of these ...
>> 
>> Introduced by commit adb9d526e982 ("x86/xsaves: Add xsaves and 
>> xrstors support for booting time").  Forgotten "inline" :-(
> 
> Ping?
> 

I already applied an equivalent patch from Borislav.

	-hpa

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-06-16  1:57 Stephen Rothwell
@ 2014-06-20  4:24 ` Stephen Rothwell
  2014-06-20  4:30   ` H. Peter Anvin
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2014-06-20  4:24 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Fenghua Yu


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

Hi all,

On Mon, 16 Jun 2014 11:57:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> In file included from arch/x86/crypto/camellia_aesni_avx_glue.c:23:0:
> arch/x86/include/asm/xsave.h:73:12: warning: 'xsave_state_booting' defined but not used [-Wunused-function]
>  static int xsave_state_booting(struct xsave_struct *fx, u64 mask)
>             ^
> 
> Lots of these ...
> 
> Introduced by commit adb9d526e982 ("x86/xsaves: Add xsaves and xrstors
> support for booting time").  Forgotten "inline" :-(

Ping?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2014-06-16  1:57 Stephen Rothwell
  2014-06-20  4:24 ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2014-06-16  1:57 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Fenghua Yu


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

Hi all,

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

In file included from arch/x86/crypto/camellia_aesni_avx_glue.c:23:0:
arch/x86/include/asm/xsave.h:73:12: warning: 'xsave_state_booting' defined but not used [-Wunused-function]
 static int xsave_state_booting(struct xsave_struct *fx, u64 mask)
            ^

Lots of these ...

Introduced by commit adb9d526e982 ("x86/xsaves: Add xsaves and xrstors
support for booting time").  Forgotten "inline" :-(

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-04-01  0:26         ` Stephen Rothwell
@ 2014-04-01  1:56           ` H. Peter Anvin
  0 siblings, 0 replies; 113+ messages in thread
From: H. Peter Anvin @ 2014-04-01  1:56 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner
  Cc: Ingo Molnar, Peter Zijlstra, linux-next, linux-kernel,
	Andi Kleen, Andrew Morton

On 03/31/2014 05:26 PM, Stephen Rothwell wrote:
> 
> And today from Linus' tree I get these:
> 
> x86_64_allmodconfig:
> 
> arch/x86/crypto/sha1_ssse3_glue.c:43:1: warning:
> 'externally_visible' attribute have effect only on public objects
> [-Wattributes] static asmlinkage void (*sha1_transform_asm)(u32 *,
> const char *, unsigned int); ^ 
> arch/x86/crypto/sha256_ssse3_glue.c:56:1: warning:
> 'externally_visible' attribute have effect only on public objects
> [-Wattributes] static asmlinkage void (*sha256_transform_asm)(const
> char *, u32 *, u64); ^ arch/x86/crypto/sha512_ssse3_glue.c:55:1:
> warning: 'externally_visible' attribute have effect only on public
> objects [-Wattributes] static asmlinkage void
> (*sha512_transform_asm)(const char *, u64 *, u64); ^
> 
> arm_multi_v7_defconfig:
> 
> drivers/irqchip/irq-sun4i.c:39:70: warning: 'externally_visible'
> attribute have effect only on public objects [-Wattributes] 
> drivers/irqchip/irq-sun4i.c:140:1: warning: 'externally_visible'
> attribute have effect only on public objects [-Wattributes] 
> drivers/irqchip/irq-armada-370-xp.c:357:1: warning:
> 'externally_visible' attribute have effect only on public objects
> [-Wattributes] drivers/irqchip/irq-gic.c:283:1: warning:
> 'externally_visible' attribute have effect only on public objects
> [-Wattributes] drivers/irqchip/irq-sirfsoc.c:51:1: warning:
> 'externally_visible' attribute have effect only on public objects
> [-Wattributes] drivers/irqchip/irq-vt8500.c:183:1: warning:
> 'externally_visible' attribute have effect only on public objects
> [-Wattributes]
> 

Please see the tree "[GIT PULL] x86 LTO changes for v3.15".

	-hpa

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-03-31 10:57       ` Stephen Rothwell
@ 2014-04-01  0:26         ` Stephen Rothwell
  2014-04-01  1:56           ` H. Peter Anvin
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2014-04-01  0:26 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, linux-next,
	linux-kernel, Andi Kleen, Andrew Morton


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

Hi Thomas,

On Mon, 31 Mar 2014 21:57:43 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 31 Mar 2014 11:45:24 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > commit 8783dd3a37a5853689e1a8fa728827a50905b912
> > Author: Stephen Boyd <sboyd@codeaurora.org>
> > Date:   Tue Mar 4 16:40:30 2014 -0800
> > 
> >     irqchip: Remove asmlinkage from static functions
> > 
> > which is in the tip tree since March 12th.
> 
> Thanks for that.
> 
> An i386_defconfig produces this:
> 
> arch/x86/kernel/syscall_32.c:14:1: warning: 'externally_visible' attribute ignored [-Wattributes]
> arch/x86/kernel/machine_kexec_32.c: In function 'machine_kexec':
> arch/x86/kernel/machine_kexec_32.c:191:12: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]

And today from Linus' tree I get these:

x86_64_allmodconfig:

arch/x86/crypto/sha1_ssse3_glue.c:43:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
 static asmlinkage void (*sha1_transform_asm)(u32 *, const char *, unsigned int);
 ^
arch/x86/crypto/sha256_ssse3_glue.c:56:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
 static asmlinkage void (*sha256_transform_asm)(const char *, u32 *, u64);
 ^
arch/x86/crypto/sha512_ssse3_glue.c:55:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
 static asmlinkage void (*sha512_transform_asm)(const char *, u64 *, u64);
 ^

arm_multi_v7_defconfig:

drivers/irqchip/irq-sun4i.c:39:70: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-sun4i.c:140:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-armada-370-xp.c:357:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-gic.c:283:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-sirfsoc.c:51:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-vt8500.c:183:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-03-31  9:45     ` Thomas Gleixner
@ 2014-03-31 10:57       ` Stephen Rothwell
  2014-04-01  0:26         ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2014-03-31 10:57 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, linux-next,
	linux-kernel, Andi Kleen, Andrew Morton


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

Hi Thomas,


On Mon, 31 Mar 2014 11:45:24 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> commit 8783dd3a37a5853689e1a8fa728827a50905b912
> Author: Stephen Boyd <sboyd@codeaurora.org>
> Date:   Tue Mar 4 16:40:30 2014 -0800
> 
>     irqchip: Remove asmlinkage from static functions
> 
> which is in the tip tree since March 12th.

Thanks for that.

An i386_defconfig produces this:

arch/x86/kernel/syscall_32.c:14:1: warning: 'externally_visible' attribute ignored [-Wattributes]
arch/x86/kernel/machine_kexec_32.c: In function 'machine_kexec':
arch/x86/kernel/machine_kexec_32.c:191:12: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-03-28  5:52   ` Stephen Rothwell
@ 2014-03-31  9:45     ` Thomas Gleixner
  2014-03-31 10:57       ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Thomas Gleixner @ 2014-03-31  9:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, linux-next,
	linux-kernel, Andi Kleen, Andrew Morton

On Fri, 28 Mar 2014, Stephen Rothwell wrote:
> > > I guess that there may be more places where "asmlinkage" is used with
> > > "static" - I assume that they are all incorrect?
> > > 
> > > $ git grep -l 'static.*asmlinkage'
> > > arch/x86/crypto/sha1_ssse3_glue.c
> > > arch/x86/crypto/sha256_ssse3_glue.c
> > > arch/x86/crypto/sha512_ssse3_glue.c
> > > drivers/irqchip/irq-armada-370-xp.c
> > > drivers/irqchip/irq-bcm2835.c
> > > drivers/irqchip/irq-gic.c
> > > drivers/irqchip/irq-mmp.c
> > > drivers/irqchip/irq-moxart.c
> > > drivers/irqchip/irq-orion.c
> > > drivers/irqchip/irq-sirfsoc.c
> > > drivers/irqchip/irq-sun4i.c
> > > drivers/irqchip/irq-vic.c
> > > drivers/irqchip/irq-vt8500.c
> > > drivers/irqchip/irq-zevio.c
> > > drivers/pnp/pnpbios/bioscalls.c
> > > scripts/checkpatch.pl
> > > 
> > > (the last two don't matter)
> > 
> > Any resolution for this?
> 
> Ping?

commit 8783dd3a37a5853689e1a8fa728827a50905b912
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Tue Mar 4 16:40:30 2014 -0800

    irqchip: Remove asmlinkage from static functions

 irq-armada-370-xp.c |    2 +-
 irq-bcm2835.c       |    4 ++--
 irq-gic.c           |    2 +-
 irq-mmp.c           |    6 ++----
 irq-moxart.c        |    2 +-
 irq-orion.c         |    2 +-
 irq-sirfsoc.c       |    2 +-
 irq-sun4i.c         |    4 ++--
 irq-vic.c           |    2 +-
 irq-vt8500.c        |    3 +--
 irq-zevio.c         |    2 +-

which is in the tip tree since March 12th.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-03-06  4:00 ` Stephen Rothwell
@ 2014-03-28  5:52   ` Stephen Rothwell
  2014-03-31  9:45     ` Thomas Gleixner
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2014-03-28  5:52 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andi Kleen, Andrew Morton


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

Hi all,

On Thu, 6 Mar 2014 15:00:10 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 24 Feb 2014 15:17:32 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the tip tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> > 
> > drivers/irqchip/irq-armada-370-xp.c:415:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> > drivers/irqchip/irq-sun4i.c:39:70: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> > drivers/irqchip/irq-sun4i.c:140:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> > drivers/irqchip/irq-gic.c:283:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> > drivers/irqchip/irq-sirfsoc.c:51:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> > drivers/irqchip/irq-vt8500.c:183:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> > 
> > Probably introduced by commit 128ea04a9885 ("lto: Make asmlinkage __visible").
> > 
> > I guess that there may be more places where "asmlinkage" is used with
> > "static" - I assume that they are all incorrect?
> > 
> > $ git grep -l 'static.*asmlinkage'
> > arch/x86/crypto/sha1_ssse3_glue.c
> > arch/x86/crypto/sha256_ssse3_glue.c
> > arch/x86/crypto/sha512_ssse3_glue.c
> > drivers/irqchip/irq-armada-370-xp.c
> > drivers/irqchip/irq-bcm2835.c
> > drivers/irqchip/irq-gic.c
> > drivers/irqchip/irq-mmp.c
> > drivers/irqchip/irq-moxart.c
> > drivers/irqchip/irq-orion.c
> > drivers/irqchip/irq-sirfsoc.c
> > drivers/irqchip/irq-sun4i.c
> > drivers/irqchip/irq-vic.c
> > drivers/irqchip/irq-vt8500.c
> > drivers/irqchip/irq-zevio.c
> > drivers/pnp/pnpbios/bioscalls.c
> > scripts/checkpatch.pl
> > 
> > (the last two don't matter)
> 
> Any resolution for this?

Ping?

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2014-03-06  6:12 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2014-03-06  6:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Stephane Eranian


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

Hi all,

After merging the tip tree, today's linux-next build (i386 defconfig)
produced this warning:

arch/x86/kernel/cpu/perf_event_intel_uncore.c: In function 'snb_uncore_imc_init_box':
arch/x86/kernel/cpu/perf_event_intel_uncore.c:1725:15: warning: unused variable 'addr_hi' [-Wunused-variable]

Introduced by commit b9e1ab6d4c05 ("perf/x86/uncore: add SNB/IVB/HSW
client uncore memory controller support") from the tip tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-02-24  4:17 Stephen Rothwell
  2014-02-24  5:56 ` Stephen Rothwell
  2014-02-24 15:48 ` Andi Kleen
@ 2014-03-06  4:00 ` Stephen Rothwell
  2014-03-28  5:52   ` Stephen Rothwell
  2 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2014-03-06  4:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andi Kleen, Andrew Morton


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

On Mon, 24 Feb 2014 15:17:32 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> drivers/irqchip/irq-armada-370-xp.c:415:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-sun4i.c:39:70: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-sun4i.c:140:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-gic.c:283:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-sirfsoc.c:51:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> drivers/irqchip/irq-vt8500.c:183:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
> 
> Probably introduced by commit 128ea04a9885 ("lto: Make asmlinkage __visible").
> 
> I guess that there may be more places where "asmlinkage" is used with
> "static" - I assume that they are all incorrect?
> 
> $ git grep -l 'static.*asmlinkage'
> arch/x86/crypto/sha1_ssse3_glue.c
> arch/x86/crypto/sha256_ssse3_glue.c
> arch/x86/crypto/sha512_ssse3_glue.c
> drivers/irqchip/irq-armada-370-xp.c
> drivers/irqchip/irq-bcm2835.c
> drivers/irqchip/irq-gic.c
> drivers/irqchip/irq-mmp.c
> drivers/irqchip/irq-moxart.c
> drivers/irqchip/irq-orion.c
> drivers/irqchip/irq-sirfsoc.c
> drivers/irqchip/irq-sun4i.c
> drivers/irqchip/irq-vic.c
> drivers/irqchip/irq-vt8500.c
> drivers/irqchip/irq-zevio.c
> drivers/pnp/pnpbios/bioscalls.c
> scripts/checkpatch.pl
> 
> (the last two don't matter)

Any resolution for this?

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-02-24 15:48 ` Andi Kleen
@ 2014-02-24 15:51   ` H. Peter Anvin
  0 siblings, 0 replies; 113+ messages in thread
From: H. Peter Anvin @ 2014-02-24 15:51 UTC (permalink / raw)
  To: Andi Kleen, Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, linux-next, linux-kernel

static asmlinkage can make sense if a pointer to the function is taken somewhere in the same translation unit.

On February 24, 2014 7:48:41 AM PST, Andi Kleen <ak@linux.intel.com> wrote:
>> I guess that there may be more places where "asmlinkage" is used with
>> "static" - I assume that they are all incorrect?
>
>Likely they are bogus yes.
>
>One issue is still the changed ABI on i386, so one has to double check
>before removing if they have arguments.
>
>-Andi

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-02-24  4:17 Stephen Rothwell
  2014-02-24  5:56 ` Stephen Rothwell
@ 2014-02-24 15:48 ` Andi Kleen
  2014-02-24 15:51   ` H. Peter Anvin
  2014-03-06  4:00 ` Stephen Rothwell
  2 siblings, 1 reply; 113+ messages in thread
From: Andi Kleen @ 2014-02-24 15:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

> I guess that there may be more places where "asmlinkage" is used with
> "static" - I assume that they are all incorrect?

Likely they are bogus yes.

One issue is still the changed ABI on i386, so one has to double check
before removing if they have arguments.

-Andi

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-02-24  6:12   ` Andrew Morton
@ 2014-02-24  6:23     ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2014-02-24  6:23 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Andi Kleen, Rashika Kheria


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

Hi Andrew,

On Sun, 23 Feb 2014 22:12:17 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Doh, I missed that.  I don't know if it's "allowed" or not, but it's
> clearly the wrong thing to do - the whole point of asmlinkage is to
> export the thing to other compilation units.
> 
> So I suppose this:
> 
> mm/process_vm_access.c:416:1: warning: no previous prototype for `compat_process_vm_rw' [-Wmissing-prototypes]
> 
> should be squashed by giving it a prototype.  Something like

Or maybe it should be static but *not* asmlinkage like process_vm_rw() ?

As far as I can see it is only used in mm/process_vm_access.c.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-02-24  5:56 ` Stephen Rothwell
@ 2014-02-24  6:12   ` Andrew Morton
  2014-02-24  6:23     ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Andrew Morton @ 2014-02-24  6:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Andi Kleen, Rashika Kheria

On Mon, 24 Feb 2014 16:56:21 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Mon, 24 Feb 2014 15:17:32 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I guess that there may be more places where "asmlinkage" is used with
> > "static" - I assume that they are all incorrect?
> > 
> > $ git grep -l 'static.*asmlinkage'
> > arch/x86/crypto/sha1_ssse3_glue.c
> > arch/x86/crypto/sha256_ssse3_glue.c
> > arch/x86/crypto/sha512_ssse3_glue.c
> 
> In fact, my x86_64 allmodconfig build produces these:
> 
> arch/x86/crypto/sha1_ssse3_glue.c:43:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
>  static asmlinkage void (*sha1_transform_asm)(u32 *, const char *, unsigned int);
>  ^
> arch/x86/crypto/sha256_ssse3_glue.c:56:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
>  static asmlinkage void (*sha256_transform_asm)(const char *, u32 *, u64);
>  ^
> arch/x86/crypto/sha512_ssse3_glue.c:55:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
>  static asmlinkage void (*sha512_transform_asm)(const char *, u64 *, u64);
>  ^
> mm/process_vm_access.c:422:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
>  {
>  ^
> 
> That last is added by commit 700d00f85598 ("mm/process_vm_access.c: mark
> function as static") from the akpm-current tree.
> 
> So is "static asmlinkage" not allowed?

Doh, I missed that.  I don't know if it's "allowed" or not, but it's
clearly the wrong thing to do - the whole point of asmlinkage is to
export the thing to other compilation units.

So I suppose this:

mm/process_vm_access.c:416:1: warning: no previous prototype for `compat_process_vm_rw' [-Wmissing-prototypes]

should be squashed by giving it a prototype.  Something like

--- a/include/linux/compat.h~a
+++ a/include/linux/compat.h
@@ -644,6 +644,13 @@ asmlinkage ssize_t compat_sys_mq_timedre
 asmlinkage long compat_sys_socketcall(int call, u32 __user *args);
 asmlinkage long compat_sys_sysctl(struct compat_sysctl_args __user *args);
 
+asmlinkage ssize_t compat_process_vm_rw(compat_pid_t pid,
+		     const struct compat_iovec __user *lvec,
+		     unsigned long liovcnt,
+		     const struct compat_iovec __user *rvec,
+		     unsigned long riovcnt,
+		     unsigned long flags, int vm_write);
+
 extern ssize_t compat_rw_copy_check_uvector(int type,
 		const struct compat_iovec __user *uvector,
 		unsigned long nr_segs,
_

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2014-02-24  4:17 Stephen Rothwell
@ 2014-02-24  5:56 ` Stephen Rothwell
  2014-02-24  6:12   ` Andrew Morton
  2014-02-24 15:48 ` Andi Kleen
  2014-03-06  4:00 ` Stephen Rothwell
  2 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2014-02-24  5:56 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andi Kleen, Rashika Kheria, Andrew Morton


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

Hi all,

On Mon, 24 Feb 2014 15:17:32 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I guess that there may be more places where "asmlinkage" is used with
> "static" - I assume that they are all incorrect?
> 
> $ git grep -l 'static.*asmlinkage'
> arch/x86/crypto/sha1_ssse3_glue.c
> arch/x86/crypto/sha256_ssse3_glue.c
> arch/x86/crypto/sha512_ssse3_glue.c

In fact, my x86_64 allmodconfig build produces these:

arch/x86/crypto/sha1_ssse3_glue.c:43:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
 static asmlinkage void (*sha1_transform_asm)(u32 *, const char *, unsigned int);
 ^
arch/x86/crypto/sha256_ssse3_glue.c:56:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
 static asmlinkage void (*sha256_transform_asm)(const char *, u32 *, u64);
 ^
arch/x86/crypto/sha512_ssse3_glue.c:55:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
 static asmlinkage void (*sha512_transform_asm)(const char *, u64 *, u64);
 ^
mm/process_vm_access.c:422:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
 {
 ^

That last is added by commit 700d00f85598 ("mm/process_vm_access.c: mark
function as static") from the akpm-current tree.

So is "static asmlinkage" not allowed?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2014-02-24  4:17 Stephen Rothwell
  2014-02-24  5:56 ` Stephen Rothwell
                   ` (2 more replies)
  0 siblings, 3 replies; 113+ messages in thread
From: Stephen Rothwell @ 2014-02-24  4:17 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andi Kleen


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

Hi all,

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

drivers/irqchip/irq-armada-370-xp.c:415:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-sun4i.c:39:70: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-sun4i.c:140:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-gic.c:283:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-sirfsoc.c:51:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-vt8500.c:183:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes]

Probably introduced by commit 128ea04a9885 ("lto: Make asmlinkage __visible").

I guess that there may be more places where "asmlinkage" is used with
"static" - I assume that they are all incorrect?

$ git grep -l 'static.*asmlinkage'
arch/x86/crypto/sha1_ssse3_glue.c
arch/x86/crypto/sha256_ssse3_glue.c
arch/x86/crypto/sha512_ssse3_glue.c
drivers/irqchip/irq-armada-370-xp.c
drivers/irqchip/irq-bcm2835.c
drivers/irqchip/irq-gic.c
drivers/irqchip/irq-mmp.c
drivers/irqchip/irq-moxart.c
drivers/irqchip/irq-orion.c
drivers/irqchip/irq-sirfsoc.c
drivers/irqchip/irq-sun4i.c
drivers/irqchip/irq-vic.c
drivers/irqchip/irq-vt8500.c
drivers/irqchip/irq-zevio.c
drivers/pnp/pnpbios/bioscalls.c
scripts/checkpatch.pl

(the last two don't matter)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2013-08-30 20:42         ` Andi Kleen
@ 2013-08-31  6:41           ` Ingo Molnar
  0 siblings, 0 replies; 113+ messages in thread
From: Ingo Molnar @ 2013-08-31  6:41 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Stephen Rothwell, Andi Kleen, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel


* Andi Kleen <ak@linux.intel.com> wrote:

> > > I've seen this pattern of deficient changelogs a dozen 
> > > times in your patches this year alone ...
> > 
> > Ping?
> 
> I've re-sent the patch already last week.

hpa was on vacation, if he doesn't pick it up I'll apply it.

> Some perf patches are also pending, there just seems to be a long 
> backlog.
> 
> http://permalink.gmane.org/gmane.linux.kernel/1548787 
> http://permalink.gmane.org/gmane.linux.kernel/1548788 
> http://permalink.gmane.org/gmane.linux.kernel/1548790 
> http://permalink.gmane.org/gmane.linux.kernel/1548791

There's no perf patches backlog. The ones you link to here were delayed 
because you (again) ignored maintainer review feedback:

  https://lkml.org/lkml/2013/8/30/370

Not sure you noticed, but kernel subsystem maintainers are not your 
repeat-everything-a-thousand-times patch submission QA machinery.

I have no problems explaining kernel contribution basics to newbies, but 
as a long-time kernel contributor you are expected to submit patch series 
whose quality is proportional to the amount of time you have already spent 
submitting patches. I.e. the longer the time you actively spent sending 
patches, the higher quality your patch series should become.

Instead what I see from you are the same problems over and over again: 
sloppy patches, ignored review feedback.

So to protect other people's higher quality patch flows maintainers that 
deal with you frequently often have to put your faulty submissions to the 
tail of their TODO list, until you show more reliable patterns of 
behavior. I will eventually have to stop taking patches from you 
permanently, if your abuse of review feedback continues.

Instead of complaining and blaming the maintainer you should increase the 
quality of your patch submissions instead.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2013-08-30  8:55       ` Stephen Rothwell
@ 2013-08-30 20:42         ` Andi Kleen
  2013-08-31  6:41           ` Ingo Molnar
  0 siblings, 1 reply; 113+ messages in thread
From: Andi Kleen @ 2013-08-30 20:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, Andi Kleen, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

> > I've seen this pattern of deficient changelogs a dozen 
> > times in your patches this year alone ...
> 
> Ping?

I've re-sent the patch already last week.

Some perf patches are also pending, there just seems to be a long 
backlog.

http://permalink.gmane.org/gmane.linux.kernel/1548787
http://permalink.gmane.org/gmane.linux.kernel/1548788
http://permalink.gmane.org/gmane.linux.kernel/1548790
http://permalink.gmane.org/gmane.linux.kernel/1548791

http://permalink.gmane.org/gmane.linux.kernel/1548665

-Andi


-- 
ak@linux.intel.com -- Speaking for myself only

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2013-08-20  6:42     ` Ingo Molnar
@ 2013-08-30  8:55       ` Stephen Rothwell
  2013-08-30 20:42         ` Andi Kleen
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2013-08-30  8:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andi Kleen, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andi Kleen


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

Hi all,

On Tue, 20 Aug 2013 08:42:09 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andi Kleen <andi@firstfloor.org> wrote:
> 
> > > > Introduced by commit 9a55fdbe941e ("x86, asmlinkage, paravirt: Add
> > > > __visible/asmlinkage to xen paravirt ops").  The 2 definitions used to be
> > > > identical ... maybe there should be only one.
> > > 
> > > Andi, please send a fix for this build warning, against 
> > > tip:x86/asmlinkage.
> > 
> > I resent the patch. Thanks for the headsup.
> 
> I suspect hpa missed it because the patch was opaque and 
> non-descriptive: the title talks about a 'warning' that is 
> supposedly fixed but the changelog does not explain what 
> warning it is and why the change matters.
> 
> Please use the customary changelog style we use in the 
> kernel:
> 
>   " Current code does (A), this has a problem when (B).
>     We can improve this doing (C), because (D)."
> 
> I've seen this pattern of deficient changelogs a dozen 
> times in your patches this year alone ...

Ping?

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2013-08-20  0:52   ` Andi Kleen
@ 2013-08-20  6:42     ` Ingo Molnar
  2013-08-30  8:55       ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Ingo Molnar @ 2013-08-20  6:42 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andi Kleen


* Andi Kleen <andi@firstfloor.org> wrote:

> > > Introduced by commit 9a55fdbe941e ("x86, asmlinkage, paravirt: Add
> > > __visible/asmlinkage to xen paravirt ops").  The 2 definitions used to be
> > > identical ... maybe there should be only one.
> > 
> > Andi, please send a fix for this build warning, against 
> > tip:x86/asmlinkage.
> 
> I resent the patch. Thanks for the headsup.

I suspect hpa missed it because the patch was opaque and 
non-descriptive: the title talks about a 'warning' that is 
supposedly fixed but the changelog does not explain what 
warning it is and why the change matters.

Please use the customary changelog style we use in the 
kernel:

  " Current code does (A), this has a problem when (B).
    We can improve this doing (C), because (D)."

I've seen this pattern of deficient changelogs a dozen 
times in your patches this year alone ...

Thanks,

        Ingo

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2013-08-19  6:58 ` Ingo Molnar
@ 2013-08-20  0:52   ` Andi Kleen
  2013-08-20  6:42     ` Ingo Molnar
  0 siblings, 1 reply; 113+ messages in thread
From: Andi Kleen @ 2013-08-20  0:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Andi Kleen, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
	Andi Kleen

> > Introduced by commit 9a55fdbe941e ("x86, asmlinkage, paravirt: Add
> > __visible/asmlinkage to xen paravirt ops").  The 2 definitions used to be
> > identical ... maybe there should be only one.
> 
> Andi, please send a fix for this build warning, against 
> tip:x86/asmlinkage.

I resent the patch. Thanks for the headsup.
-Andi

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2013-08-19  4:26 Stephen Rothwell
@ 2013-08-19  6:58 ` Ingo Molnar
  2013-08-20  0:52   ` Andi Kleen
  0 siblings, 1 reply; 113+ messages in thread
From: Ingo Molnar @ 2013-08-19  6:58 UTC (permalink / raw)
  To: Stephen Rothwell, Andi Kleen
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Andi Kleen


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> arch/x86/kernel/paravirt.c:66:0: warning: "DEF_NATIVE" redefined [enabled by default]
>  #define DEF_NATIVE(ops, name, code)     \
>  ^
> In file included from arch/x86/include/asm/ptrace.h:65:0,
>                  from arch/x86/include/asm/alternative.h:8,
>                  from arch/x86/include/asm/bitops.h:16,
>                  from include/linux/bitops.h:22,
>                  from include/linux/kernel.h:10,
>                  from include/linux/cache.h:4,
>                  from include/linux/time.h:4,
>                  from include/linux/stat.h:18,
>                  from include/linux/module.h:10,
>                  from arch/x86/kernel/paravirt.c:22:
> arch/x86/include/asm/paravirt_types.h:391:0: note: this is the location of the previous definition
>  #define DEF_NATIVE(ops, name, code)      \
>  ^
> 
> Introduced by commit 9a55fdbe941e ("x86, asmlinkage, paravirt: Add
> __visible/asmlinkage to xen paravirt ops").  The 2 definitions used to be
> identical ... maybe there should be only one.

Andi, please send a fix for this build warning, against 
tip:x86/asmlinkage.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2013-08-19  4:26 Stephen Rothwell
  2013-08-19  6:58 ` Ingo Molnar
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2013-08-19  4:26 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Andi Kleen


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

Hi all,

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

arch/x86/kernel/paravirt.c:66:0: warning: "DEF_NATIVE" redefined [enabled by default]
 #define DEF_NATIVE(ops, name, code)     \
 ^
In file included from arch/x86/include/asm/ptrace.h:65:0,
                 from arch/x86/include/asm/alternative.h:8,
                 from arch/x86/include/asm/bitops.h:16,
                 from include/linux/bitops.h:22,
                 from include/linux/kernel.h:10,
                 from include/linux/cache.h:4,
                 from include/linux/time.h:4,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from arch/x86/kernel/paravirt.c:22:
arch/x86/include/asm/paravirt_types.h:391:0: note: this is the location of the previous definition
 #define DEF_NATIVE(ops, name, code)      \
 ^

Introduced by commit 9a55fdbe941e ("x86, asmlinkage, paravirt: Add
__visible/asmlinkage to xen paravirt ops").  The 2 definitions used to be
identical ... maybe there should be only one.

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2013-02-02  5:58 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2013-02-02  5:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Dave Hansen


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

Hi all,

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

arch/x86/mm/numa.c: In function 'setup_node_data':
arch/x86/mm/numa.c:222:3: warning: passing argument 1 of '__phys_addr_nodebug' makes integer from pointer without a cast [enabled by default]
arch/x86/include/asm/page_64.h:12:29: note: expected 'long unsigned int' but argument is of type 'void *'

Introduced by commit a25b9316841c ("x86, mm: Make DEBUG_VIRTUAL work
earlier in boot").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2013-02-02  5:55 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2013-02-02  5:55 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Alok N Kataria


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

Hi all,

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

arch/x86/kernel/kvm.c: At top level:
arch/x86/kernel/kvm.c:509:2: warning: initialization from incompatible pointer type [enabled by default]
arch/x86/kernel/kvm.c:509:2: warning: (near initialization for 'x86_hyper_kvm.x2apic_available') [enabled by default]

Introduced by commit 4cca6ea04d31 ("x86/apic: Allow x2apic without IR on
VMware platform").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2013-02-02  5:51 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2013-02-02  5:51 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Dave Hansen


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

Hi all,

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

arch/x86/kernel/kvm.c: In function 'kvm_register_steal_time':
arch/x86/kernel/kvm.c:302:3: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'phys_addr_t' [-Wformat]

Introduced by commit 5dfd486c4750 ("x86, kvm: Fix kvm's use of __pa() on
percpu areas").

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2013-01-30 11:41 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2013-01-30 11:41 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Dave Hansen


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

Hi all,

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

arch/x86/mm/numa.c: In function 'setup_node_data':
arch/x86/mm/numa.c:222:3: warning: passing argument 1 of '__phys_addr_nodebug' makes integer from pointer without a cast [enabled by default]
arch/x86/include/asm/page_64.h:12:29: note: expected 'long unsigned int' but argument is of type 'void *'

Introduced by commit a25b9316841c ("x86, mm: Make DEBUG_VIRTUAL work
earlier in boot").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2012-10-01 14:54 Stephen Rothwell
@ 2012-10-01 16:10 ` Josh Triplett
  0 siblings, 0 replies; 113+ messages in thread
From: Josh Triplett @ 2012-10-01 16:10 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Tue, Oct 02, 2012 at 12:54:23AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (sparc64 defconfig)
> produced this warning:
> 
> include/linux/efi.h:503:13: warning: 'efi_enter_virtual_mode' defined but not used [-Wunused-function]
> include/linux/efi.h:504:13: warning: 'efi_late_init' defined but not used [-Wunused-function]
> include/linux/efi.h:505:13: warning: 'efi_free_boot_services' defined but not used [-Wunused-function]
> 
> Introduced by commit f383a1e37bc3 ("efi: Add a stub for
> efi_enter_virtual_mode on non-x86") and following patches.  These
> function definitions should be "static inline".

Already fixed in the current version of those patches in tip.

- Josh Triplett

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2012-10-01 14:54 Stephen Rothwell
  2012-10-01 16:10 ` Josh Triplett
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2012-10-01 14:54 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Josh Triplett


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

Hi all,

After merging the tip tree, today's linux-next build (sparc64 defconfig)
produced this warning:

include/linux/efi.h:503:13: warning: 'efi_enter_virtual_mode' defined but not used [-Wunused-function]
include/linux/efi.h:504:13: warning: 'efi_late_init' defined but not used [-Wunused-function]
include/linux/efi.h:505:13: warning: 'efi_free_boot_services' defined but not used [-Wunused-function]

Introduced by commit f383a1e37bc3 ("efi: Add a stub for
efi_enter_virtual_mode on non-x86") and following patches.  These
function definitions should be "static inline".
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2012-09-27  7:46 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2012-09-27  7:46 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel


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

Hi all,

After merging the tip tree, today's linux-next build (powerpc allnoconfig)
produced this warning:

mm/memory.c: In function 'do_prot_none':
mm/memory.c:3463:6: warning: unused variable 'node' [-Wunused-variable]

Introduced by commit 39d6cb39a817 ("mm/mpol: Use special PROT_NONE to
migrate pages").

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2011-09-14  9:37 ` Thomas Gleixner
@ 2011-09-14  9:43   ` Shan Hai
  0 siblings, 0 replies; 113+ messages in thread
From: Shan Hai @ 2011-09-14  9:43 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Yong Zhang

On 09/14/2011 05:37 PM, Thomas Gleixner wrote:
> On Wed, 14 Sep 2011, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc allnoconfig)
>> produced this warning:
>>
>> lib/atomic64.c: In function 'lock_addr':
>> lib/atomic64.c:42:2: warning: return from incompatible pointer type
>>
>> Introduced by commit f59ca05871a0 ("locking, lib/atomic64: Annotate
>> atomic64_lock::lock as raw").  This function (which is declared to return
>> "spinlock_t *") is now returning "raw_spinlock_t *".
> My bad, it seems I picked the wrong version of the patch.

Hi Thomas,

Please pick the V4 patch, the last one which I have sent to you,
I am sorry for the subject line it indicates V3 :(

Thanks
Shan Hai

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2011-09-14  6:34 Stephen Rothwell
  2011-09-14  7:49 ` Yong Zhang
@ 2011-09-14  9:37 ` Thomas Gleixner
  2011-09-14  9:43   ` Shan Hai
  1 sibling, 1 reply; 113+ messages in thread
From: Thomas Gleixner @ 2011-09-14  9:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, H. Peter Anvin, Peter Zijlstra, linux-next,
	linux-kernel, Shan Hai, Yong Zhang

On Wed, 14 Sep 2011, Stephen Rothwell wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc allnoconfig)
> produced this warning:
> 
> lib/atomic64.c: In function 'lock_addr':
> lib/atomic64.c:42:2: warning: return from incompatible pointer type
> 
> Introduced by commit f59ca05871a0 ("locking, lib/atomic64: Annotate
> atomic64_lock::lock as raw").  This function (which is declared to return
> "spinlock_t *") is now returning "raw_spinlock_t *".

My bad, it seems I picked the wrong version of the patch.

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2011-09-14  6:34 Stephen Rothwell
@ 2011-09-14  7:49 ` Yong Zhang
  2011-09-14  9:37 ` Thomas Gleixner
  1 sibling, 0 replies; 113+ messages in thread
From: Yong Zhang @ 2011-09-14  7:49 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Shan Hai

On Wed, Sep 14, 2011 at 04:34:55PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc allnoconfig)
> produced this warning:
> 
> lib/atomic64.c: In function 'lock_addr':
> lib/atomic64.c:42:2: warning: return from incompatible pointer type
> 
> Introduced by commit f59ca05871a0 ("locking, lib/atomic64: Annotate
> atomic64_lock::lock as raw").  This function (which is declared to return
> "spinlock_t *") is now returning "raw_spinlock_t *".

Oh, we still have something left to clean.

Does below patch help?

---
From: Yong Zhang <yong.zhang0@gmail.com>
Subject: [PATCH] lib: atomic64: change the type of local lock to raw_spinlock_t

There are still some leftovers of commit f59ca058
[locking, lib/atomic64: Annotate atomic64_lock::lock as raw]

Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Cc: Shan Hai <haishan.bai@gmail.com>
---
 lib/atomic64.c |   22 +++++++++++-----------
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/lib/atomic64.c b/lib/atomic64.c
index 9db8dea..f9c5b29 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -33,7 +33,7 @@ static union {
 	char pad[L1_CACHE_BYTES];
 } atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
 
-static inline spinlock_t *lock_addr(const atomic64_t *v)
+static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
 {
 	unsigned long addr = (unsigned long) v;
 
@@ -45,7 +45,7 @@ static inline spinlock_t *lock_addr(const atomic64_t *v)
 long long atomic64_read(const atomic64_t *v)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 	long long val;
 
 	raw_spin_lock_irqsave(lock, flags);
@@ -58,7 +58,7 @@ EXPORT_SYMBOL(atomic64_read);
 void atomic64_set(atomic64_t *v, long long i)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 
 	raw_spin_lock_irqsave(lock, flags);
 	v->counter = i;
@@ -69,7 +69,7 @@ EXPORT_SYMBOL(atomic64_set);
 void atomic64_add(long long a, atomic64_t *v)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 
 	raw_spin_lock_irqsave(lock, flags);
 	v->counter += a;
@@ -80,7 +80,7 @@ EXPORT_SYMBOL(atomic64_add);
 long long atomic64_add_return(long long a, atomic64_t *v)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 	long long val;
 
 	raw_spin_lock_irqsave(lock, flags);
@@ -93,7 +93,7 @@ EXPORT_SYMBOL(atomic64_add_return);
 void atomic64_sub(long long a, atomic64_t *v)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 
 	raw_spin_lock_irqsave(lock, flags);
 	v->counter -= a;
@@ -104,7 +104,7 @@ EXPORT_SYMBOL(atomic64_sub);
 long long atomic64_sub_return(long long a, atomic64_t *v)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 	long long val;
 
 	raw_spin_lock_irqsave(lock, flags);
@@ -117,7 +117,7 @@ EXPORT_SYMBOL(atomic64_sub_return);
 long long atomic64_dec_if_positive(atomic64_t *v)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 	long long val;
 
 	raw_spin_lock_irqsave(lock, flags);
@@ -132,7 +132,7 @@ EXPORT_SYMBOL(atomic64_dec_if_positive);
 long long atomic64_cmpxchg(atomic64_t *v, long long o, long long n)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 	long long val;
 
 	raw_spin_lock_irqsave(lock, flags);
@@ -147,7 +147,7 @@ EXPORT_SYMBOL(atomic64_cmpxchg);
 long long atomic64_xchg(atomic64_t *v, long long new)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 	long long val;
 
 	raw_spin_lock_irqsave(lock, flags);
@@ -161,7 +161,7 @@ EXPORT_SYMBOL(atomic64_xchg);
 int atomic64_add_unless(atomic64_t *v, long long a, long long u)
 {
 	unsigned long flags;
-	spinlock_t *lock = lock_addr(v);
+	raw_spinlock_t *lock = lock_addr(v);
 	int ret = 0;
 
 	raw_spin_lock_irqsave(lock, flags);
-- 
1.7.4.1

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2011-09-14  6:34 Stephen Rothwell
  2011-09-14  7:49 ` Yong Zhang
  2011-09-14  9:37 ` Thomas Gleixner
  0 siblings, 2 replies; 113+ messages in thread
From: Stephen Rothwell @ 2011-09-14  6:34 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Shan Hai, Yong Zhang


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

Hi all,

After merging the tip tree, today's linux-next build (powerpc allnoconfig)
produced this warning:

lib/atomic64.c: In function 'lock_addr':
lib/atomic64.c:42:2: warning: return from incompatible pointer type

Introduced by commit f59ca05871a0 ("locking, lib/atomic64: Annotate
atomic64_lock::lock as raw").  This function (which is declared to return
"spinlock_t *") is now returning "raw_spinlock_t *".
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2011-09-14  6:22 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2011-09-14  6:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, John Stultz


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

Hi all,

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

kernel/time/alarmtimer.c: In function 'alarmtimer_rtc_interface_setup':
kernel/time/alarmtimer.c:106:26: warning: ignoring return value of 'class_interface_register', declared with attribute warn_unused_result

Introduced by commit 8bc0dafb5cf3 ("alarmtimers: Rework RTC device
selection using class interface").

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2010-11-29  1:11 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2010-11-29  1:11 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel


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

Hi all,

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

kernel/sched.c: In function 'sched_destroy_group':
kernel/sched.c:8098: warning: 'i' is used uninitialized in this function
kernel/sched.c:8088: note: 'i' was declared here

Introduced by commit 3d4b47b4b040c9d77dd68104cfc1055d89a55afd ("sched:
Implement on-demand (active) cfs_rq list").  I think this is a real bug.

[The wrong function is mentioned above, the actual function is
unregister_fair_sched_group() - presumably gcc has confused itself via
inlining.]
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-09-03  9:04   ` Wu Fengguang
@ 2010-09-03 10:07     ` Haicheng Li
  0 siblings, 0 replies; 113+ messages in thread
From: Haicheng Li @ 2010-09-03 10:07 UTC (permalink / raw)
  To: Wu Fengguang
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Andi Kleen

Wu Fengguang wrote:
> On Fri, Sep 03, 2010 at 10:12:01AM +0800, Stephen Rothwell wrote:
>> On Fri, 3 Sep 2010 12:10:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>>> produced this warning:
>>>
>>> arch/x86/mm/init_64.c: In function 'kernel_physical_mapping_init':
>>> arch/x86/mm/init_64.c:601: warning: 'addr' may be used uninitialized in this function
>>>
>>> The code does look suspicious ... 'addr' gets declared and then passed to
>>> a function, but is not set anywhere ...
>> Forgot to say:
>>
>> Introduced by commit 9b861528a8012e7bc4d1f7bae07395b225331477 ("x86-64,
>> mem: Update all PGDs for direct mapping and vmemmap mapping changes").
> 
> 
> The original patch has the following line, however get lost some time
> later:
> 
>         http://www.spinics.net/lists/linux-mm/msg08152.html
> 
> ===
> x86, mm: fix uninitialized addr in kernel_physical_mapping_init()
> 
> This re-adds the lost chunk in commit 9b861528a80.
> 
> CC: Haicheng Li <haicheng.li@linux.intel.com>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> ---
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 64e7bc2..74f0f35 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -570,6 +570,7 @@ kernel_physical_mapping_init(unsigned long start,
>  
>  	start = (unsigned long)__va(start);
>  	end = (unsigned long)__va(end);
> +	addr = start;

weird, this line was in my original patch: http://lkml.org/lkml/2010/8/20/166

Acked-by: Haicheng Li <haicheng.li@linux.intel.com>

>  	for (; start < end; start = next) {
>  		pgd_t *pgd = pgd_offset_k(start);
> 

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-09-03  2:12 ` Stephen Rothwell
@ 2010-09-03  9:04   ` Wu Fengguang
  2010-09-03 10:07     ` Haicheng Li
  0 siblings, 1 reply; 113+ messages in thread
From: Wu Fengguang @ 2010-09-03  9:04 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Haicheng Li, Andi Kleen

On Fri, Sep 03, 2010 at 10:12:01AM +0800, Stephen Rothwell wrote:
> On Fri, 3 Sep 2010 12:10:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> > 
> > arch/x86/mm/init_64.c: In function 'kernel_physical_mapping_init':
> > arch/x86/mm/init_64.c:601: warning: 'addr' may be used uninitialized in this function
> > 
> > The code does look suspicious ... 'addr' gets declared and then passed to
> > a function, but is not set anywhere ...
> 
> Forgot to say:
> 
> Introduced by commit 9b861528a8012e7bc4d1f7bae07395b225331477 ("x86-64,
> mem: Update all PGDs for direct mapping and vmemmap mapping changes").


The original patch has the following line, however get lost some time
later:

        http://www.spinics.net/lists/linux-mm/msg08152.html

===
x86, mm: fix uninitialized addr in kernel_physical_mapping_init()

This re-adds the lost chunk in commit 9b861528a80.

CC: Haicheng Li <haicheng.li@linux.intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 64e7bc2..74f0f35 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -570,6 +570,7 @@ kernel_physical_mapping_init(unsigned long start,
 
 	start = (unsigned long)__va(start);
 	end = (unsigned long)__va(end);
+	addr = start;
 
 	for (; start < end; start = next) {
 		pgd_t *pgd = pgd_offset_k(start);

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-09-03  2:10 Stephen Rothwell
@ 2010-09-03  2:12 ` Stephen Rothwell
  2010-09-03  9:04   ` Wu Fengguang
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2010-09-03  2:12 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Haicheng Li, Andi Kleen, Wu Fengguang


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

On Fri, 3 Sep 2010 12:10:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> arch/x86/mm/init_64.c: In function 'kernel_physical_mapping_init':
> arch/x86/mm/init_64.c:601: warning: 'addr' may be used uninitialized in this function
> 
> The code does look suspicious ... 'addr' gets declared and then passed to
> a function, but is not set anywhere ...

Forgot to say:

Introduced by commit 9b861528a8012e7bc4d1f7bae07395b225331477 ("x86-64,
mem: Update all PGDs for direct mapping and vmemmap mapping changes").

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2010-09-03  2:10 Stephen Rothwell
  2010-09-03  2:12 ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2010-09-03  2:10 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Haicheng Li, Andi Kleen, Wu Fengguang


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

Hi all,

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

arch/x86/mm/init_64.c: In function 'kernel_physical_mapping_init':
arch/x86/mm/init_64.c:601: warning: 'addr' may be used uninitialized in this function

The code does look suspicious ... 'addr' gets declared and then passed to
a function, but is not set anywhere ...

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2010-05-17  5:58 Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2010-05-17  5:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Tony Breeds, Benjamin Herrenschmidt


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

Hi all,

After merging the staging-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

kernel/mutex.c: In function '__mutex_lock_common':
kernel/mutex.c:148: warning: unused variable 'timeout'

Introduced by commit 227945799cc10d77c6ef812f3eb8a61a78689454 ("mutex:
Fix optimistic spinning vs. BKL") for a build with
CONFIG_MUTEX_SPIN_ON_OWNER not set.

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-03-17  7:02 ` Ingo Molnar
@ 2010-03-17  8:02   ` KOSAKI Motohiro
  0 siblings, 0 replies; 113+ messages in thread
From: KOSAKI Motohiro @ 2010-03-17  8:02 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: kosaki.motohiro, Stephen Rothwell, Thomas Gleixner,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the tip tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> > 
> > kernel/sched.c: In function 'SYSC_sched_getaffinity':
> > kernel/sched.c:4915: warning: comparison of distinct pointer types lacks a cast
> 
> I already reported this yesterday, see:
> 
>   http://patchwork.kernel.org/patch/86244/

yup, very thanks.

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-03-17  3:57 Stephen Rothwell
  2010-03-17  4:00 ` KOSAKI Motohiro
@ 2010-03-17  7:02 ` Ingo Molnar
  2010-03-17  8:02   ` KOSAKI Motohiro
  1 sibling, 1 reply; 113+ messages in thread
From: Ingo Molnar @ 2010-03-17  7:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, H. Peter Anvin, Peter Zijlstra, linux-next,
	linux-kernel, KOSAKI Motohiro


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> kernel/sched.c: In function 'SYSC_sched_getaffinity':
> kernel/sched.c:4915: warning: comparison of distinct pointer types lacks a cast

I already reported this yesterday, see:

  http://patchwork.kernel.org/patch/86244/

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-03-17  4:00 ` KOSAKI Motohiro
@ 2010-03-17  4:52   ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2010-03-17  4:52 UTC (permalink / raw)
  To: KOSAKI Motohiro
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel


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

Hi,

On Wed, 17 Mar 2010 13:00:00 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>
> yup. I've posted the fixing patch today.

Excellent.

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-03-17  3:57 Stephen Rothwell
@ 2010-03-17  4:00 ` KOSAKI Motohiro
  2010-03-17  4:52   ` Stephen Rothwell
  2010-03-17  7:02 ` Ingo Molnar
  1 sibling, 1 reply; 113+ messages in thread
From: KOSAKI Motohiro @ 2010-03-17  4:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: kosaki.motohiro, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> kernel/sched.c: In function 'SYSC_sched_getaffinity':
> kernel/sched.c:4915: warning: comparison of distinct pointer types lacks a cast
> 
> Introduced by commit cd3d8031eb4311e516329aee03c79a08333141f1 ("sched:
> sched_getaffinity(): Allow less than NR_CPUS length").  Just a usage of
> min() with different types.

yup. I've posted the fixing patch today.

thanks!

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2010-03-17  3:57 Stephen Rothwell
  2010-03-17  4:00 ` KOSAKI Motohiro
  2010-03-17  7:02 ` Ingo Molnar
  0 siblings, 2 replies; 113+ messages in thread
From: Stephen Rothwell @ 2010-03-17  3:57 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, KOSAKI Motohiro


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

Hi all,

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

kernel/sched.c: In function 'SYSC_sched_getaffinity':
kernel/sched.c:4915: warning: comparison of distinct pointer types lacks a cast

Introduced by commit cd3d8031eb4311e516329aee03c79a08333141f1 ("sched:
sched_getaffinity(): Allow less than NR_CPUS length").  Just a usage of
min() with different types.

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-02-23  8:52 ` Yinghai Lu
@ 2010-02-23 10:43   ` Stephen Rothwell
  0 siblings, 0 replies; 113+ messages in thread
From: Stephen Rothwell @ 2010-02-23 10:43 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel


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

Hi,

On Tue, 23 Feb 2010 00:52:25 -0800 Yinghai Lu <yinghai@kernel.org> wrote:
>
> please check

This patch fixes the warnings for me, thanks.

> [PATCH] sparsemem: fix compiling with ppc
> 
> Stephen reported:
> build (powerpc
> ppc64_defconfig) produced these warnings:
> 
> mm/sparse.c: In function 'sparse_init':
> mm/sparse.c:488: warning: unused variable 'map_count'
> mm/sparse.c:484: warning: unused variable 'size2'
> mm/sparse.c:481: warning: unused variable 'map_map'
> mm/sparse.c: At top level:
> mm/sparse.c:442: warning: 'sparse_early_mem_maps_alloc_node' defined but not used
> 
> Introduced by commit 9bdac914240759457175ac0d6529a37d2820bc4d
> ("sparsemem: Put mem map for one node together").
> 
> use macro to fix them
> 
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>

Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

* Re: linux-next: build warning after merge of the tip tree
  2010-02-23  5:01 Stephen Rothwell
@ 2010-02-23  8:52 ` Yinghai Lu
  2010-02-23 10:43   ` Stephen Rothwell
  0 siblings, 1 reply; 113+ messages in thread
From: Yinghai Lu @ 2010-02-23  8:52 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: Peter Zijlstra, linux-next, linux-kernel

On 02/22/2010 09:01 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
> 
> mm/sparse.c: In function 'sparse_init':
> mm/sparse.c:488: warning: unused variable 'map_count'
> mm/sparse.c:484: warning: unused variable 'size2'
> mm/sparse.c:481: warning: unused variable 'map_map'
> mm/sparse.c: At top level:
> mm/sparse.c:442: warning: 'sparse_early_mem_maps_alloc_node' defined but not used
> 
> Introduced by commit 9bdac914240759457175ac0d6529a37d2820bc4d
> ("sparsemem: Put mem map for one node together").
> 

please check


[PATCH] sparsemem: fix compiling with ppc

Stephen reported:
build (powerpc
ppc64_defconfig) produced these warnings:

mm/sparse.c: In function 'sparse_init':
mm/sparse.c:488: warning: unused variable 'map_count'
mm/sparse.c:484: warning: unused variable 'size2'
mm/sparse.c:481: warning: unused variable 'map_map'
mm/sparse.c: At top level:
mm/sparse.c:442: warning: 'sparse_early_mem_maps_alloc_node' defined but not used

Introduced by commit 9bdac914240759457175ac0d6529a37d2820bc4d
("sparsemem: Put mem map for one node together").

use macro to fix them

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

diff --git a/mm/sparse.c b/mm/sparse.c
index 9b6b93a..22896d5 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -439,6 +439,7 @@ void __init sparse_mem_maps_populate_node(struct page **map_map,
 }
 #endif /* !CONFIG_SPARSEMEM_VMEMMAP */
 
+#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
 static void __init sparse_early_mem_maps_alloc_node(struct page **map_map,
 				 unsigned long pnum_begin,
 				 unsigned long pnum_end,
@@ -447,8 +448,7 @@ static void __init sparse_early_mem_maps_alloc_node(struct page **map_map,
 	sparse_mem_maps_populate_node(map_map, pnum_begin, pnum_end,
 					 map_count, nodeid);
 }
-
-#ifndef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
+#else
 static struct page __init *sparse_early_mem_map_alloc(unsigned long pnum)
 {
 	struct page *map;
@@ -478,14 +478,17 @@ void __init sparse_init(void)
 {
 	unsigned long pnum;
 	struct page *map;
-	struct page **map_map;
 	unsigned long *usemap;
 	unsigned long **usemap_map;
-	int size, size2;
+	int size;
 	int nodeid_begin = 0;
 	unsigned long pnum_begin = 0;
 	unsigned long usemap_count;
+#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
 	unsigned long map_count;
+	int size2;
+	struct page **map_map;
+#endif
 
 	/*
 	 * map is using big page (aka 2M in x86 64 bit)

^ permalink raw reply	[flat|nested] 113+ messages in thread

* linux-next: build warning after merge of the tip tree
@ 2010-02-23  5:01 Stephen Rothwell
  2010-02-23  8:52 ` Yinghai Lu
  0 siblings, 1 reply; 113+ messages in thread
From: Stephen Rothwell @ 2010-02-23  5:01 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Yinghai Lu


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

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

mm/sparse.c: In function 'sparse_init':
mm/sparse.c:488: warning: unused variable 'map_count'
mm/sparse.c:484: warning: unused variable 'size2'
mm/sparse.c:481: warning: unused variable 'map_map'
mm/sparse.c: At top level:
mm/sparse.c:442: warning: 'sparse_early_mem_maps_alloc_node' defined but not used

Introduced by commit 9bdac914240759457175ac0d6529a37d2820bc4d
("sparsemem: Put mem map for one node together").

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

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

^ permalink raw reply	[flat|nested] 113+ messages in thread

end of thread, back to index

Thread overview: 113+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-19  6:57 linux-next: build warning after merge of the tip tree Stephen Rothwell
2020-05-19  7:12 ` Steve French
  -- strict thread matches above, loose matches on Subject: below --
2020-05-21 11:56 Stephen Rothwell
2020-04-28  6:29 Stephen Rothwell
2020-03-30  2:47 Stephen Rothwell
2020-03-31 21:57 ` Stephen Rothwell
2020-04-01 10:25   ` Thomas Gleixner
2020-04-01 22:00     ` Stephen Rothwell
2020-04-01 22:39       ` Thomas Gleixner
2020-04-13  0:01         ` Stephen Rothwell
2020-04-14  8:42           ` Thomas Gleixner
2020-01-20  5:38 Stephen Rothwell
2020-01-20  6:00 ` Viresh Kumar
2020-01-07  5:43 Stephen Rothwell
2020-01-07  7:16 ` Ingo Molnar
2020-01-07  7:22   ` Shile Zhang
2019-07-26  3:05 Stephen Rothwell
2019-07-26  4:49 ` Josh Poimboeuf
2019-07-26  5:49   ` Stephen Rothwell
2018-11-06  0:46 Stephen Rothwell
2018-12-19  0:55 ` Stephen Rothwell
2018-09-11  3:53 Stephen Rothwell
2018-09-12 19:35 ` Thomas Gleixner
2018-03-23  2:28 Stephen Rothwell
2018-03-23  8:31 ` Christoph Hellwig
2018-03-23  9:57   ` Stephen Rothwell
2018-03-16  5:37 Stephen Rothwell
2018-03-16  5:52 ` Dou Liyang
2018-03-16  6:04   ` Dou Liyang
2018-03-16  7:55 ` Thomas Gleixner
2018-01-10  4:41 Stephen Rothwell
2017-09-27  3:42 Stephen Rothwell
2017-09-27 11:50 ` Prarit Bhargava
2017-06-28  7:15 Stephen Rothwell
2017-06-23  3:58 Stephen Rothwell
2017-06-23  4:00 ` Stephen Rothwell
2017-06-23  4:10   ` Michael Ellerman
2017-06-23  4:22     ` Stephen Rothwell
2016-12-14  2:28 Stephen Rothwell
2016-12-14  7:24 ` Ingo Molnar
2016-12-14  8:05   ` Richard Weinberger
2016-12-14  8:26     ` Stephen Rothwell
2016-12-14  8:10   ` Stephen Rothwell
2016-07-24  5:32 Stephen Rothwell
2016-07-25  7:16 ` Thomas Gleixner
2016-07-25 13:11   ` Daniel Lezcano
2016-07-25 14:53     ` Rich Felker
2016-07-25 16:42       ` Mark Brown
2016-07-25 17:54         ` Rich Felker
2016-07-25 14:48   ` Rich Felker
2016-04-07  5:26 Stephen Rothwell
2016-04-07  8:48 ` Ingo Molnar
2016-04-07 12:03   ` Stephen Rothwell
2015-05-12  3:35 Stephen Rothwell
2014-08-05  0:58 Stephen Rothwell
2014-07-18  5:00 Stephen Rothwell
2014-07-18 19:16 ` H. Peter Anvin
2014-07-18 19:57   ` Andy Lutomirski
2014-07-18 20:05     ` H. Peter Anvin
2014-07-18 20:08       ` Andy Lutomirski
2014-07-18 20:15         ` H. Peter Anvin
2014-07-18 20:20           ` Andy Lutomirski
2014-07-18 20:50             ` H. Peter Anvin
2014-06-16  1:57 Stephen Rothwell
2014-06-20  4:24 ` Stephen Rothwell
2014-06-20  4:30   ` H. Peter Anvin
2014-06-20  4:35     ` Stephen Rothwell
2014-03-06  6:12 Stephen Rothwell
2014-02-24  4:17 Stephen Rothwell
2014-02-24  5:56 ` Stephen Rothwell
2014-02-24  6:12   ` Andrew Morton
2014-02-24  6:23     ` Stephen Rothwell
2014-02-24 15:48 ` Andi Kleen
2014-02-24 15:51   ` H. Peter Anvin
2014-03-06  4:00 ` Stephen Rothwell
2014-03-28  5:52   ` Stephen Rothwell
2014-03-31  9:45     ` Thomas Gleixner
2014-03-31 10:57       ` Stephen Rothwell
2014-04-01  0:26         ` Stephen Rothwell
2014-04-01  1:56           ` H. Peter Anvin
2013-08-19  4:26 Stephen Rothwell
2013-08-19  6:58 ` Ingo Molnar
2013-08-20  0:52   ` Andi Kleen
2013-08-20  6:42     ` Ingo Molnar
2013-08-30  8:55       ` Stephen Rothwell
2013-08-30 20:42         ` Andi Kleen
2013-08-31  6:41           ` Ingo Molnar
2013-02-02  5:58 Stephen Rothwell
2013-02-02  5:55 Stephen Rothwell
2013-02-02  5:51 Stephen Rothwell
2013-01-30 11:41 Stephen Rothwell
2012-10-01 14:54 Stephen Rothwell
2012-10-01 16:10 ` Josh Triplett
2012-09-27  7:46 Stephen Rothwell
2011-09-14  6:34 Stephen Rothwell
2011-09-14  7:49 ` Yong Zhang
2011-09-14  9:37 ` Thomas Gleixner
2011-09-14  9:43   ` Shan Hai
2011-09-14  6:22 Stephen Rothwell
2010-11-29  1:11 Stephen Rothwell
2010-09-03  2:10 Stephen Rothwell
2010-09-03  2:12 ` Stephen Rothwell
2010-09-03  9:04   ` Wu Fengguang
2010-09-03 10:07     ` Haicheng Li
2010-05-17  5:58 Stephen Rothwell
2010-03-17  3:57 Stephen Rothwell
2010-03-17  4:00 ` KOSAKI Motohiro
2010-03-17  4:52   ` Stephen Rothwell
2010-03-17  7:02 ` Ingo Molnar
2010-03-17  8:02   ` KOSAKI Motohiro
2010-02-23  5:01 Stephen Rothwell
2010-02-23  8:52 ` Yinghai Lu
2010-02-23 10:43   ` Stephen Rothwell

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git