Re: linux-next: build warning after merge of the akpm tree

[Vijayanand Jitta]

On 1/28/2021 2:16 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> lib/stackdepot.c: In function 'is_stack_depot_disabled':
> lib/stackdepot.c:154:2: warning: ignoring return value of 'kstrtobool' 
> declared with attribute 'warn_unused_result' [-Wunused-result]
>   154 |  kstrtobool(str, _depot_disable);
>   |  ^
> 
> Introduced by commit
> 
>   b9779abb09a8 ("lib: stackdepot: add support to disable stack depot")
> 
> Interestingly, we have 2 declarations of kstrtobool - one in
> linux/kernel.h (which has __must_check) and one in linux/strings.h
> (which doesn't).
> 

I have sent out the fix to lkml, Copied it below for your reference.
Please Feel free to apply or squash it to the original commit.

Thanks,
Vijay

--
From: Vijayanand Jitta 

fix the below ignoring return value warning for kstrtobool
in is_stack_depot_disabled function.

lib/stackdepot.c: In function 'is_stack_depot_disabled':
lib/stackdepot.c:154:2: warning: ignoring return value of 'kstrtobool'
declared with attribute 'warn_unused_result' [-Wunused-result]

Fixes: b9779abb09a8 ("lib: stackdepot: add support to disable stack depot")
Signed-off-by: Vijayanand Jitta 
---
 lib/stackdepot.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index cc21116..49f67a0 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -151,8 +151,10 @@ static struct stack_record **stack_table;

 static int __init is_stack_depot_disabled(char *str)
 {
-   kstrtobool(str, _depot_disable);
-   if (stack_depot_disable) {
+   int ret;
+
+   ret = kstrtobool(str, _depot_disable);
+   if (!ret && stack_depot_disable) {
pr_info("Stack Depot is disabled\n");
stack_table = NULL;
}
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi all,

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

lib/stackdepot.c: In function 'is_stack_depot_disabled':
lib/stackdepot.c:154:2: warning: ignoring return value of 'kstrtobool' declared 
with attribute 'warn_unused_result' [-Wunused-result]
  154 |  kstrtobool(str, _depot_disable);
  |  ^

Introduced by commit

  b9779abb09a8 ("lib: stackdepot: add support to disable stack depot")

Interestingly, we have 2 declarations of kstrtobool - one in
linux/kernel.h (which has __must_check) and one in linux/strings.h
(which doesn't).

-- 
Cheers,
Stephen Rothwell


pgpsSBJVoToT6.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Michael,

On Thu, 10 Dec 2020 11:19:45 +1100 Michael Ellerman  wrote:
>
> Stephen Rothwell  writes:
> >
> > On Wed, 09 Dec 2020 15:44:35 +1100 Michael Ellerman  
> > wrote:  
> >>
> >> They should really be in DATA_DATA or similar shouldn't they?  
> >
> > No other architecture appears t need them ...  
> 
> Any arch with orphan-handling=warn should see them I thought?

I did an x86_64 allyesconfig build (same compiler (more or less) and
same source) and it produces none of these sections.  The only
difference in UBSAN CONFIG_ options was that CONFIG_UBSAN_UNREACHABLE
is not set in the x86_64 build.

-- 
Cheers,
Stephen Rothwell


pgp1wuG44t3b_.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm tree

[Michael Ellerman]

Stephen Rothwell  writes:
> Hi Michael,
>
> On Wed, 09 Dec 2020 15:44:35 +1100 Michael Ellerman  
> wrote:
>>
>> They should really be in DATA_DATA or similar shouldn't they?
>
> No other architecture appears t need them ...

Any arch with orphan-handling=warn should see them I thought?

cheers

Re: linux-next: build warning after merge of the akpm tree

[Kees Cook]

On Tue, Dec 08, 2020 at 11:01:57PM +1100, Stephen Rothwell wrote:
> Hi Stephen,
> 
> On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell  
> wrote:
> >
> > Hi all,
> > 
> > After merging the akpm tree, today's linux-next build (powerpc
> > allyesconfig) produced warnings like this:
> > 
> > ld: warning: orphan section `.data..Lubsan_data177' from 
> > `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
> > `.data..Lubsan_data177'
> > 
> > (lots of these latter ones)
> 
> 781584 of them today!
> 
> > I don't know what produced these, but it is in the akpm-current or
> > akpm trees.
> 
> Presumably the result of commit
> 
>   186c3e18dba3 ("ubsan: enable for all*config builds")
> 
> from the akpm-current tree.
> 
> arch/powerpc/kernel/vmlinux.lds.S has:
> 
> #ifdef CONFIG_PPC32
> .data : AT(ADDR(.data) - LOAD_OFFSET) {
> DATA_DATA
> #ifdef CONFIG_UBSAN
> *(.data..Lubsan_data*)
> *(.data..Lubsan_type*)
> #endif
> *(.data.rel*)
> *(SDATA_MAIN)
> 
> added by commit
> 
>   beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* 
> sections explicitly")
> 
> in 2018, but no equivalent for 64 bit.
> 
> I will try the following patch tomorrow:
> 
> From: Stephen Rothwell 
> Date: Tue, 8 Dec 2020 22:58:24 +1100
> Subject: [PATCH] powerpc: Add .data..Lubsan_data*/.data..Lubsan_type* 
> sections explicitly
> 
> Similarly to commit
> 
>   beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* 
> sections explicitly")
> 
> since CONFIG_UBSAN bits can now be enabled for all*config.
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/powerpc/kernel/vmlinux.lds.S | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
> b/arch/powerpc/kernel/vmlinux.lds.S
> index 3b4c26e94328..0318ba436f34 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -296,6 +296,10 @@ SECTIONS
>  #else
>   .data : AT(ADDR(.data) - LOAD_OFFSET) {
>   DATA_DATA
> +#ifdef CONFIG_UBSAN
> + *(.data..Lubsan_data*)
> + *(.data..Lubsan_type*)
> +#endif
>   *(.data.rel*)
>   *(.toc1)
>   *(.branch_lt)
> -- 
> 2.29.2
> 
> -- 
> Cheers,
> Stephen Rothwell

Reviewed-by: Kees Cook 

Thanks for figuring this one out. :) Andrew, can you add this to your
ubsan patch stack, or do you want me to resend it to you directly?


-- 
Kees Cook

Re: linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi all,

On Tue, 8 Dec 2020 23:01:57 +1100 Stephen Rothwell  
wrote:
>
> I will try the following patch tomorrow:
> 
> From: Stephen Rothwell 
> Date: Tue, 8 Dec 2020 22:58:24 +1100
> Subject: [PATCH] powerpc: Add .data..Lubsan_data*/.data..Lubsan_type* 
> sections explicitly
> 
> Similarly to commit
> 
>   beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* 
> sections explicitly")
> 
> since CONFIG_UBSAN bits can now be enabled for all*config.
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/powerpc/kernel/vmlinux.lds.S | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
> b/arch/powerpc/kernel/vmlinux.lds.S
> index 3b4c26e94328..0318ba436f34 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -296,6 +296,10 @@ SECTIONS
>  #else
>   .data : AT(ADDR(.data) - LOAD_OFFSET) {
>   DATA_DATA
> +#ifdef CONFIG_UBSAN
> + *(.data..Lubsan_data*)
> + *(.data..Lubsan_type*)
> +#endif
>   *(.data.rel*)
>   *(.toc1)
>   *(.branch_lt)
> -- 
> 2.29.2

This got rid of all the warnings.

-- 
Cheers,
Stephen Rothwell


pgpCXGxHd4nt2.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm tree

[Dmitry Vyukov]

On Mon, Dec 7, 2020 at 1:52 PM Marco Elver  wrote:
>
> On Mon, 7 Dec 2020 at 13:38, 'Dmitry Vyukov' via kasan-dev
>  wrote:
> > On Mon, Dec 7, 2020 at 1:08 PM Dmitry Vyukov  wrote:
> > > > > Hi all,
> > > > >
> > > > > After merging the akpm tree, today's linux-next build (powerpc
> > > > > allyesconfig) produced warnings like this:
> > > > >
> > > > > kernel/kcov.c:296:14: warning: conflicting types for built-in 
> > > > > function '__sanitizer_cov_trace_switch'; expected 'void(long unsigned 
> > > > > int,  void *)' [-Wbuiltin-declaration-mismatch]
> > > > >   296 | void notrace __sanitizer_cov_trace_switch(u64 val, u64 *cases)
> > > > >   |  ^~~~
> > > >
> > > > Odd.  clang wants that signature, according to
> > > > https://clang.llvm.org/docs/SanitizerCoverage.html.  But gcc seems to
> > > > want a different signature.  Beats me - best I can do is to cc various
> > > > likely culprits ;)
> > > >
> > > > Which gcc version?  Did you recently update gcc?
> > > >
> > > > > ld: warning: orphan section `.data..Lubsan_data177' from 
> > > > > `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
> > > > > `.data..Lubsan_data177'
> > > > >
> > > > > (lots of these latter ones)
> > > > >
> > > > > I don't know what produced these, but it is in the akpm-current or
> > > > > akpm trees.
> > >
> > > I can reproduce this in x86_64 build as well but only if I enable
> > > UBSAN as well. There were some recent UBSAN changes by Kees, so maybe
> > > that's what affected the warning.
> > > Though, the warning itself looks legit and unrelated to UBSAN. In
> > > fact, if the compiler expects long and we accept u64, it may be broken
> > > on 32-bit arches...
> >
> > No, I think it works, the argument should be uint64.
> >
> > I think both gcc and clang signatures are correct and both want
> > uint64_t. The question is just how uint64_t is defined :) The old
> > printf joke that one can't write portable format specifier for
> > uint64_t.
> >
> > What I know so far:
> > clang 11 does not produce this warning even with obviously wrong
> > signatures (e.g. short).
> > I wasn't able to trigger it with gcc on 32-bits at all. KCOV is not
> > supported on i386 and on arm I got no warnings even with obviously
> > wrong signatures (e.g. short).
> > Using "(unsigned long val, void *cases)" fixes the warning on x86_64.
> >
> > I am still puzzled why gcc considers this as a builtin because we
> > don't enable -fsanitizer-coverage on this file. I am also puzzled how
> > UBSAN affects things.
>
> It might be some check-for-builtins check gone wrong if it enables any
> one of the sanitizers. That would be confirmed if it works with
>
> UBSAN_SANITIZE_kcov.o := n

Yes, it "fixes" the warning.
Initially I thought it's not a good solution because we want to detect
UBSAN bugs in KCOV. But on second thought, if UBSAN detects a bug in
KCOV, it may lead to infinite recursion. We already disable all other
sanitizers on KCOV for this reason, so it's reasonable to disable
UBSAN as well. And as a side effect it "resolves" the warning as well.
I mailed:
https://lore.kernel.org/lkml/20201209100152.2492072-1-dvyu...@google.com/T/#u

Thanks

> > We could change the signature to long, but it feels wrong/dangerous
> > because the variable should really be 64-bits (long is broken on
> > 32-bits).
> > Or we could introduce a typedef that is long on 64-bits and 'long
> > long' on 32-bits.

Re: linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Michael,

On Wed, 09 Dec 2020 15:44:35 +1100 Michael Ellerman  wrote:
>
> They should really be in DATA_DATA or similar shouldn't they?

No other architecture appears t need them ...

-- 
Cheers,
Stephen Rothwell


pgpHxEGuWLRlX.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm tree

[Michael Ellerman]

Stephen Rothwell  writes:
> Hi Stephen,
>
> On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell  
> wrote:
>>
>> Hi all,
>> 
>> After merging the akpm tree, today's linux-next build (powerpc
>> allyesconfig) produced warnings like this:
>> 
>> ld: warning: orphan section `.data..Lubsan_data177' from 
>> `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
>> `.data..Lubsan_data177'
>> 
>> (lots of these latter ones)
>
> 781584 of them today!
>
>> I don't know what produced these, but it is in the akpm-current or
>> akpm trees.
>
> Presumably the result of commit
>
>   186c3e18dba3 ("ubsan: enable for all*config builds")
>
> from the akpm-current tree.
>
> arch/powerpc/kernel/vmlinux.lds.S has:
>
> #ifdef CONFIG_PPC32
> .data : AT(ADDR(.data) - LOAD_OFFSET) {
> DATA_DATA
> #ifdef CONFIG_UBSAN
> *(.data..Lubsan_data*)
> *(.data..Lubsan_type*)
> #endif
> *(.data.rel*)
> *(SDATA_MAIN)
>
> added by commit
>
>   beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* 
> sections explicitly")
>
> in 2018, but no equivalent for 64 bit.

They should really be in DATA_DATA or similar shouldn't they?

cheers

Re: linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Stephen,

On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> allyesconfig) produced warnings like this:
> 
> ld: warning: orphan section `.data..Lubsan_data177' from 
> `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
> `.data..Lubsan_data177'
> 
> (lots of these latter ones)

781584 of them today!

> I don't know what produced these, but it is in the akpm-current or
> akpm trees.

Presumably the result of commit

  186c3e18dba3 ("ubsan: enable for all*config builds")

from the akpm-current tree.

arch/powerpc/kernel/vmlinux.lds.S has:

#ifdef CONFIG_PPC32
.data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
#ifdef CONFIG_UBSAN
*(.data..Lubsan_data*)
*(.data..Lubsan_type*)
#endif
*(.data.rel*)
*(SDATA_MAIN)

added by commit

  beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* 
sections explicitly")

in 2018, but no equivalent for 64 bit.

I will try the following patch tomorrow:

From: Stephen Rothwell 
Date: Tue, 8 Dec 2020 22:58:24 +1100
Subject: [PATCH] powerpc: Add .data..Lubsan_data*/.data..Lubsan_type* sections 
explicitly

Similarly to commit

  beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* 
sections explicitly")

since CONFIG_UBSAN bits can now be enabled for all*config.

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/kernel/vmlinux.lds.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index 3b4c26e94328..0318ba436f34 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -296,6 +296,10 @@ SECTIONS
 #else
.data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
+#ifdef CONFIG_UBSAN
+   *(.data..Lubsan_data*)
+   *(.data..Lubsan_type*)
+#endif
*(.data.rel*)
*(.toc1)
*(.branch_lt)
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell


pgpeKDSMESCKg.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm tree

[Marco Elver]

On Mon, 7 Dec 2020 at 13:38, 'Dmitry Vyukov' via kasan-dev
 wrote:
> On Mon, Dec 7, 2020 at 1:08 PM Dmitry Vyukov  wrote:
> > > > Hi all,
> > > >
> > > > After merging the akpm tree, today's linux-next build (powerpc
> > > > allyesconfig) produced warnings like this:
> > > >
> > > > kernel/kcov.c:296:14: warning: conflicting types for built-in function 
> > > > '__sanitizer_cov_trace_switch'; expected 'void(long unsigned int,  void 
> > > > *)' [-Wbuiltin-declaration-mismatch]
> > > >   296 | void notrace __sanitizer_cov_trace_switch(u64 val, u64 *cases)
> > > >   |  ^~~~
> > >
> > > Odd.  clang wants that signature, according to
> > > https://clang.llvm.org/docs/SanitizerCoverage.html.  But gcc seems to
> > > want a different signature.  Beats me - best I can do is to cc various
> > > likely culprits ;)
> > >
> > > Which gcc version?  Did you recently update gcc?
> > >
> > > > ld: warning: orphan section `.data..Lubsan_data177' from 
> > > > `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
> > > > `.data..Lubsan_data177'
> > > >
> > > > (lots of these latter ones)
> > > >
> > > > I don't know what produced these, but it is in the akpm-current or
> > > > akpm trees.
> >
> > I can reproduce this in x86_64 build as well but only if I enable
> > UBSAN as well. There were some recent UBSAN changes by Kees, so maybe
> > that's what affected the warning.
> > Though, the warning itself looks legit and unrelated to UBSAN. In
> > fact, if the compiler expects long and we accept u64, it may be broken
> > on 32-bit arches...
>
> No, I think it works, the argument should be uint64.
>
> I think both gcc and clang signatures are correct and both want
> uint64_t. The question is just how uint64_t is defined :) The old
> printf joke that one can't write portable format specifier for
> uint64_t.
>
> What I know so far:
> clang 11 does not produce this warning even with obviously wrong
> signatures (e.g. short).
> I wasn't able to trigger it with gcc on 32-bits at all. KCOV is not
> supported on i386 and on arm I got no warnings even with obviously
> wrong signatures (e.g. short).
> Using "(unsigned long val, void *cases)" fixes the warning on x86_64.
>
> I am still puzzled why gcc considers this as a builtin because we
> don't enable -fsanitizer-coverage on this file. I am also puzzled how
> UBSAN affects things.

It might be some check-for-builtins check gone wrong if it enables any
one of the sanitizers. That would be confirmed if it works with

UBSAN_SANITIZE_kcov.o := n

> We could change the signature to long, but it feels wrong/dangerous
> because the variable should really be 64-bits (long is broken on
> 32-bits).
> Or we could introduce a typedef that is long on 64-bits and 'long
> long' on 32-bits.

Re: linux-next: build warning after merge of the akpm tree

[Dmitry Vyukov]

On Mon, Dec 7, 2020 at 1:08 PM Dmitry Vyukov  wrote:
> > > Hi all,
> > >
> > > After merging the akpm tree, today's linux-next build (powerpc
> > > allyesconfig) produced warnings like this:
> > >
> > > kernel/kcov.c:296:14: warning: conflicting types for built-in function 
> > > '__sanitizer_cov_trace_switch'; expected 'void(long unsigned int,  void 
> > > *)' [-Wbuiltin-declaration-mismatch]
> > >   296 | void notrace __sanitizer_cov_trace_switch(u64 val, u64 *cases)
> > >   |  ^~~~
> >
> > Odd.  clang wants that signature, according to
> > https://clang.llvm.org/docs/SanitizerCoverage.html.  But gcc seems to
> > want a different signature.  Beats me - best I can do is to cc various
> > likely culprits ;)
> >
> > Which gcc version?  Did you recently update gcc?
> >
> > > ld: warning: orphan section `.data..Lubsan_data177' from 
> > > `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
> > > `.data..Lubsan_data177'
> > >
> > > (lots of these latter ones)
> > >
> > > I don't know what produced these, but it is in the akpm-current or
> > > akpm trees.
>
> I can reproduce this in x86_64 build as well but only if I enable
> UBSAN as well. There were some recent UBSAN changes by Kees, so maybe
> that's what affected the warning.
> Though, the warning itself looks legit and unrelated to UBSAN. In
> fact, if the compiler expects long and we accept u64, it may be broken
> on 32-bit arches...

No, I think it works, the argument should be uint64.

I think both gcc and clang signatures are correct and both want
uint64_t. The question is just how uint64_t is defined :) The old
printf joke that one can't write portable format specifier for
uint64_t.

What I know so far:
clang 11 does not produce this warning even with obviously wrong
signatures (e.g. short).
I wasn't able to trigger it with gcc on 32-bits at all. KCOV is not
supported on i386 and on arm I got no warnings even with obviously
wrong signatures (e.g. short).
Using "(unsigned long val, void *cases)" fixes the warning on x86_64.

I am still puzzled why gcc considers this as a builtin because we
don't enable -fsanitizer-coverage on this file. I am also puzzled how
UBSAN affects things.

We could change the signature to long, but it feels wrong/dangerous
because the variable should really be 64-bits (long is broken on
32-bits).
Or we could introduce a typedef that is long on 64-bits and 'long
long' on 32-bits.

Re: linux-next: build warning after merge of the akpm tree

[Dmitry Vyukov]

On Sat, Dec 5, 2020 at 6:19 AM Andrew Morton  wrote:
>
> On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell  
> wrote:
>
> > Hi all,
> >
> > After merging the akpm tree, today's linux-next build (powerpc
> > allyesconfig) produced warnings like this:
> >
> > kernel/kcov.c:296:14: warning: conflicting types for built-in function 
> > '__sanitizer_cov_trace_switch'; expected 'void(long unsigned int,  void *)' 
> > [-Wbuiltin-declaration-mismatch]
> >   296 | void notrace __sanitizer_cov_trace_switch(u64 val, u64 *cases)
> >   |  ^~~~
>
> Odd.  clang wants that signature, according to
> https://clang.llvm.org/docs/SanitizerCoverage.html.  But gcc seems to
> want a different signature.  Beats me - best I can do is to cc various
> likely culprits ;)
>
> Which gcc version?  Did you recently update gcc?
>
> > ld: warning: orphan section `.data..Lubsan_data177' from 
> > `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
> > `.data..Lubsan_data177'
> >
> > (lots of these latter ones)
> >
> > I don't know what produced these, but it is in the akpm-current or
> > akpm trees.

I can reproduce this in x86_64 build as well but only if I enable
UBSAN as well. There were some recent UBSAN changes by Kees, so maybe
that's what affected the warning.
Though, the warning itself looks legit and unrelated to UBSAN. In
fact, if the compiler expects long and we accept u64, it may be broken
on 32-bit arches...

I have gcc version 10.2.0 (Debian 10.2.0-15)
On next-20201207
config is defconfig +
CONFIG_KCOV=y
CONFIG_KCOV_ENABLE_COMPARISONS=y
CONFIG_UBSAN=y

$ make -j8 kernel/kcov.o
  CC  kernel/kcov.o
kernel/kcov.c:296:14: warning: conflicting types for built-in function
‘__sanitizer_cov_trace_switch’; expected ‘void(long unsigned int,
void *)’ [-Wbuiltin-declaration-mismatch]
  296 | void notrace __sanitizer_cov_trace_switch(u64 val, u64 *cases)

Re: linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

On Fri, 4 Dec 2020 21:19:23 -0800 Andrew Morton  
wrote:
>
> Odd.  clang wants that signature, according to
> https://clang.llvm.org/docs/SanitizerCoverage.html.  But gcc seems to
> want a different signature.  Beats me - best I can do is to cc various
> likely culprits ;)
> 
> Which gcc version?  Did you recently update gcc?

gcc (Debian 10.2.0-15) 10.2.0

Not recently upgraded.

-- 
Cheers,
Stephen Rothwell


pgpClXrQuZRe_.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm tree

[Andrew Morton]

On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell  
wrote:

> Hi all,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> allyesconfig) produced warnings like this:
> 
> kernel/kcov.c:296:14: warning: conflicting types for built-in function 
> '__sanitizer_cov_trace_switch'; expected 'void(long unsigned int,  void *)' 
> [-Wbuiltin-declaration-mismatch]
>   296 | void notrace __sanitizer_cov_trace_switch(u64 val, u64 *cases)
>   |  ^~~~

Odd.  clang wants that signature, according to
https://clang.llvm.org/docs/SanitizerCoverage.html.  But gcc seems to
want a different signature.  Beats me - best I can do is to cc various
likely culprits ;)

Which gcc version?  Did you recently update gcc?

> ld: warning: orphan section `.data..Lubsan_data177' from 
> `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
> `.data..Lubsan_data177'
> 
> (lots of these latter ones)
> 
> I don't know what produced these, but it is in the akpm-current or
> akpm trees.

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi all,

After merging the akpm tree, today's linux-next build (powerpc
allyesconfig) produced warnings like this:

kernel/kcov.c:296:14: warning: conflicting types for built-in function 
'__sanitizer_cov_trace_switch'; expected 'void(long unsigned int,  void *)' 
[-Wbuiltin-declaration-mismatch]
  296 | void notrace __sanitizer_cov_trace_switch(u64 val, u64 *cases)
  |  ^~~~

ld: warning: orphan section `.data..Lubsan_data177' from 
`arch/powerpc/oprofile/op_model_pa6t.o' being placed in section 
`.data..Lubsan_data177'

(lots of these latter ones)

I don't know what produced these, but it is in the akpm-current or
akpm trees.

-- 
Cheers,
Stephen Rothwell


pgpNriuQnuihp.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm tree

[Dave Rodgman]

On 30/11/2018 5:40 am, Stephen Rothwell wrote:
> After merging the akpm tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> lib/lzo/lzo1x_compress.c: In function 'lzo1x_1_do_compress':
> lib/lzo/lzo1x_compress.c:239:14: warning: 'm_pos' may be used uninitialized 
> in this function [-Wmaybe-uninitialized]
> m_off = ip - m_pos;
> ~~~^~~
> Probably introduced by patch
>
>"lib/lzo: implement run-length encoding"
> or
>"lib/lzo: separate lzo-rle from lzo"

Apologies, I didn't spot this (I think it's gcc only - clang, which I
was testing with, seems smart enough not to report this false positive).

I've fixed it in the latest patchset (v4):

https://lkml.org/lkml/2018/11/30/972

Dave
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: linux-next: build warning after merge of the akpm tree

[Dave Rodgman]

On 30/11/2018 5:40 am, Stephen Rothwell wrote:
> After merging the akpm tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> lib/lzo/lzo1x_compress.c: In function 'lzo1x_1_do_compress':
> lib/lzo/lzo1x_compress.c:239:14: warning: 'm_pos' may be used uninitialized 
> in this function [-Wmaybe-uninitialized]
> m_off = ip - m_pos;
> ~~~^~~
> Probably introduced by patch
>
>"lib/lzo: implement run-length encoding"
> or
>"lib/lzo: separate lzo-rle from lzo"

Apologies, I didn't spot this (I think it's gcc only - clang, which I
was testing with, seems smart enough not to report this false positive).

I've fixed it in the latest patchset (v4):

https://lkml.org/lkml/2018/11/30/972

Dave
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

lib/lzo/lzo1x_compress.c: In function 'lzo1x_1_do_compress':
lib/lzo/lzo1x_compress.c:239:14: warning: 'm_pos' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
   m_off = ip - m_pos;
   ~~~^~~
Probably introduced by patch

  "lib/lzo: implement run-length encoding"
or
  "lib/lzo: separate lzo-rle from lzo"

-- 
Cheers,
Stephen Rothwell


pgpvl_4ETKZoU.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

lib/lzo/lzo1x_compress.c: In function 'lzo1x_1_do_compress':
lib/lzo/lzo1x_compress.c:239:14: warning: 'm_pos' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
   m_off = ip - m_pos;
   ~~~^~~
Probably introduced by patch

  "lib/lzo: implement run-length encoding"
or
  "lib/lzo: separate lzo-rle from lzo"

-- 
Cheers,
Stephen Rothwell


pgpvl_4ETKZoU.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm tree

[Arnd Bergmann]

On Tue, Aug 1, 2017 at 8:15 AM, Huang, Ying  wrote:
> From 7a7ff76d7bcbd7affda169b29abcf3dafa38052e Mon Sep 17 00:00:00 2001
> From: Huang Ying 
> Date: Tue, 1 Aug 2017 14:12:21 +0800
> Subject: [PATCH] mm, THP, swap: Silence a compiler warning
>
> To fix the following compiler warning,
>
> mm/swapfile.c: In function 'reuse_swap_page':
> mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   unsigned long offset;
> ^
>
> This is a false positive report, but we should silence it anyway.

Looks ok, I ran into this too, and came to the same conclusion.
I normally try to find a way to reorganize the code without adding
a bogus initialization, but here I could not find come up with anything
better than what you did.

Arnd

Re: linux-next: build warning after merge of the akpm tree

[Arnd Bergmann]

On Tue, Aug 1, 2017 at 8:15 AM, Huang, Ying  wrote:
> From 7a7ff76d7bcbd7affda169b29abcf3dafa38052e Mon Sep 17 00:00:00 2001
> From: Huang Ying 
> Date: Tue, 1 Aug 2017 14:12:21 +0800
> Subject: [PATCH] mm, THP, swap: Silence a compiler warning
>
> To fix the following compiler warning,
>
> mm/swapfile.c: In function 'reuse_swap_page':
> mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   unsigned long offset;
> ^
>
> This is a false positive report, but we should silence it anyway.

Looks ok, I ran into this too, and came to the same conclusion.
I normally try to find a way to reorganize the code without adding
a bogus initialization, but here I could not find come up with anything
better than what you did.

Arnd

Re: linux-next: build warning after merge of the akpm tree

[Huang, Ying]

Hi, Stephen,

Thanks for reporting.

Stephen Rothwell  writes:

> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> mm/swapfile.c: In function 'reuse_swap_page':
> mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   unsigned long offset;
> ^
>
> Introduced by commit
>
>   e16cd4930836 ("mm, THP, swap: make reuse_swap_page() works for THP swapped 
> out")

This looks like a false positive reporting and not reported by my
compiler and kbuild compiler (gcc-6).  But anyway, we should silence it.

Best Regards,
Huang, Ying

-->8--
>From 7a7ff76d7bcbd7affda169b29abcf3dafa38052e Mon Sep 17 00:00:00 2001
From: Huang Ying 
Date: Tue, 1 Aug 2017 14:12:21 +0800
Subject: [PATCH] mm, THP, swap: Silence a compiler warning

To fix the following compiler warning,

mm/swapfile.c: In function 'reuse_swap_page':
mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  unsigned long offset;
^

This is a false positive report, but we should silence it anyway.

Reported-by: Stephen Rothwell 
Signed-off-by: "Huang, Ying" 
---
 mm/swapfile.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 32434541cc12..64a94f70e867 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1426,7 +1426,7 @@ static int page_trans_huge_map_swapcount(struct page 
*page, int *total_mapcount,
 int *total_swapcount)
 {
int i, map_swapcount, _total_mapcount, _total_swapcount;
-   unsigned long offset;
+   unsigned long offset = 0;
struct swap_info_struct *si;
struct swap_cluster_info *ci = NULL;
unsigned char *map = NULL;
-- 
2.13.2

Re: linux-next: build warning after merge of the akpm tree

[Huang, Ying]

Hi, Stephen,

Thanks for reporting.

Stephen Rothwell  writes:

> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> mm/swapfile.c: In function 'reuse_swap_page':
> mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   unsigned long offset;
> ^
>
> Introduced by commit
>
>   e16cd4930836 ("mm, THP, swap: make reuse_swap_page() works for THP swapped 
> out")

This looks like a false positive reporting and not reported by my
compiler and kbuild compiler (gcc-6).  But anyway, we should silence it.

Best Regards,
Huang, Ying

-->8--
>From 7a7ff76d7bcbd7affda169b29abcf3dafa38052e Mon Sep 17 00:00:00 2001
From: Huang Ying 
Date: Tue, 1 Aug 2017 14:12:21 +0800
Subject: [PATCH] mm, THP, swap: Silence a compiler warning

To fix the following compiler warning,

mm/swapfile.c: In function 'reuse_swap_page':
mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  unsigned long offset;
^

This is a false positive report, but we should silence it anyway.

Reported-by: Stephen Rothwell 
Signed-off-by: "Huang, Ying" 
---
 mm/swapfile.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 32434541cc12..64a94f70e867 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1426,7 +1426,7 @@ static int page_trans_huge_map_swapcount(struct page 
*page, int *total_mapcount,
 int *total_swapcount)
 {
int i, map_swapcount, _total_mapcount, _total_swapcount;
-   unsigned long offset;
+   unsigned long offset = 0;
struct swap_info_struct *si;
struct swap_cluster_info *ci = NULL;
unsigned char *map = NULL;
-- 
2.13.2

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

mm/swapfile.c: In function 'reuse_swap_page':
mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  unsigned long offset;
^

Introduced by commit

  e16cd4930836 ("mm, THP, swap: make reuse_swap_page() works for THP swapped 
out")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

mm/swapfile.c: In function 'reuse_swap_page':
mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  unsigned long offset;
^

Introduced by commit

  e16cd4930836 ("mm, THP, swap: make reuse_swap_page() works for THP swapped 
out")

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm tree

[Wei Yang]

Thanks, I just found it. 

On Mon, Jun 26, 2017 at 04:30:12PM +1000, Stephen Rothwell wrote:
>Hi Andrew,
>
>After merging the akpm tree, today's linux-next build (x86_64
>allmodconfig) produced this warning:
>
>mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
>mm/memory_hotplug.c:891:16: warning: unused variable 'i' [-Wunused-variable]
>  unsigned long i;
>^
>
>Introduced by commit
>
>  7fb537987bb3 ("mm/memory_hotplug: remove duplicate call for set_page_links")
>
>-- 
>Cheers,
>Stephen Rothwell

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature

Re: linux-next: build warning after merge of the akpm tree

[Wei Yang]

Thanks, I just found it. 

On Mon, Jun 26, 2017 at 04:30:12PM +1000, Stephen Rothwell wrote:
>Hi Andrew,
>
>After merging the akpm tree, today's linux-next build (x86_64
>allmodconfig) produced this warning:
>
>mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
>mm/memory_hotplug.c:891:16: warning: unused variable 'i' [-Wunused-variable]
>  unsigned long i;
>^
>
>Introduced by commit
>
>  7fb537987bb3 ("mm/memory_hotplug: remove duplicate call for set_page_links")
>
>-- 
>Cheers,
>Stephen Rothwell

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
mm/memory_hotplug.c:891:16: warning: unused variable 'i' [-Wunused-variable]
  unsigned long i;
^

Introduced by commit

  7fb537987bb3 ("mm/memory_hotplug: remove duplicate call for set_page_links")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
mm/memory_hotplug.c:891:16: warning: unused variable 'i' [-Wunused-variable]
  unsigned long i;
^

Introduced by commit

  7fb537987bb3 ("mm/memory_hotplug: remove duplicate call for set_page_links")

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm tree

[Davidlohr Bueso]

On Tue, 2014-05-20 at 07:36 +1000, Stephen Rothwell wrote:
> Hi,
> 
> On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso  wrote:
> >
> > On Mon, 2014-05-19 at 18:13 +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > > 
> > > After merging the akpm tree, today's linux-next build (arm
> > > multi_v7_defconfig) produced these warnings:
> > > 
> > > 
> > > ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
> > > [enabled by default]
> > > ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
> > > 'ipcns_chain.rwsem') [enabled by default]
> > > ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
> > > [enabled by default]
> > > ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
> > > 'ipcns_chain.rwsem') [enabled by default]
> > > 
> > > and many more in other files ...
> > 
> > Hmm are all the warning the same? Is this just on arm? have you seen it
> > in other archs? (Could you please send me the .config)
> 
> The warnings were all the same, I saw it only on arm (since that was
> what I built) and I mentioned the config above.
> 
> > > Presumably a result of commit fe2038c57c03 ("rwsem: Support optimistic
> > > spinning").
> > 
> > If CONFIG_SMP, we add two new fields to the rwsem structure
> > (include/linux/rwsem.h) and likewise we update the
> > __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
> > something like that is to be using the spinlock variant
> > (rwsem-spinlock.h).
> 
> Actually quite a few architectures do set
> CONFIG_RWSEM_GENERIC_SPINLOCK, and so wouldn't it make more sense to
> actually directly test that?

Both are equivalent, I have no preference. I've sent a formal fix to the
-tip folks, I guess I'll let them choose.

Thanks,
Davidlohr

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

Re: linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi,

On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso  wrote:
>
> On Mon, 2014-05-19 at 18:13 +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm tree, today's linux-next build (arm
> > multi_v7_defconfig) produced these warnings:
> > 
> > 
> > ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
> > [enabled by default]
> > ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
> > 'ipcns_chain.rwsem') [enabled by default]
> > ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
> > [enabled by default]
> > ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
> > 'ipcns_chain.rwsem') [enabled by default]
> > 
> > and many more in other files ...
> 
> Hmm are all the warning the same? Is this just on arm? have you seen it
> in other archs? (Could you please send me the .config)

The warnings were all the same, I saw it only on arm (since that was
what I built) and I mentioned the config above.

> > Presumably a result of commit fe2038c57c03 ("rwsem: Support optimistic
> > spinning").
> 
> If CONFIG_SMP, we add two new fields to the rwsem structure
> (include/linux/rwsem.h) and likewise we update the
> __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
> something like that is to be using the spinlock variant
> (rwsem-spinlock.h).

Actually quite a few architectures do set
CONFIG_RWSEM_GENERIC_SPINLOCK, and so wouldn't it make more sense to
actually directly test that?

> The fix for that would be:
> 
> diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
> index 3e108f1..091d993 100644
> --- a/include/linux/rwsem.h
> +++ b/include/linux/rwsem.h
> @@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
>  # define __RWSEM_DEP_MAP_INIT(lockname)
>  #endif
>  
> -#ifdef CONFIG_SMP
> +#if defined(CONFIG_SMP) && defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)

so

#if defined(CONFIG_SMP) && !defined(CONFIG_RWSEM_GENERIC_SPINLOCK)

?

> This was picked up today by -tip maintainers, so I guess it should also
> be removed from -mm.

Was a fix also picked up?

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


signature.asc
Description: PGP signature

Re: linux-next: build warning after merge of the akpm tree

[Andrew Morton]

On Mon, 19 May 2014 13:56:20 -0700 Davidlohr Bueso  wrote:

> On Mon, 2014-05-19 at 12:48 -0700, Andrew Morton wrote:
> > On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso  wrote:
> > 
> > > > Presumably a result of commit fe2038c57c03 ("rwsem: Support optimistic
> > > > spinning").
> > > 
> > > If CONFIG_SMP, we add two new fields to the rwsem structure
> > > (include/linux/rwsem.h) and likewise we update the
> > > __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
> > > something like that is to be using the spinlock variant
> > > (rwsem-spinlock.h).
> > > 
> > > The fix for that would be:
> > > 
> > > diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
> > > index 3e108f1..091d993 100644
> > > --- a/include/linux/rwsem.h
> > > +++ b/include/linux/rwsem.h
> > > @@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore 
> > > *sem)
> > >  # define __RWSEM_DEP_MAP_INIT(lockname)
> > >  #endif
> > >  
> > > -#ifdef CONFIG_SMP
> > > +#if defined(CONFIG_SMP) && defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
> > >  #define __RWSEM_INITIALIZER(name)  \
> > > { RWSEM_UNLOCKED_VALUE, \
> > >   __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \
> > 
> > that squishes the warnings for me.
> 
> You guys know best, but shouldn't this change be routed through -tip?

Yes, this patch and the two fixes I have applied to it should be sent
that way.  If/when they turn up in -next I will drop my copies.

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

Re: linux-next: build warning after merge of the akpm tree

[Davidlohr Bueso]

On Mon, 2014-05-19 at 12:48 -0700, Andrew Morton wrote:
> On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso  wrote:
> 
> > > Presumably a result of commit fe2038c57c03 ("rwsem: Support optimistic
> > > spinning").
> > 
> > If CONFIG_SMP, we add two new fields to the rwsem structure
> > (include/linux/rwsem.h) and likewise we update the
> > __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
> > something like that is to be using the spinlock variant
> > (rwsem-spinlock.h).
> > 
> > The fix for that would be:
> > 
> > diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
> > index 3e108f1..091d993 100644
> > --- a/include/linux/rwsem.h
> > +++ b/include/linux/rwsem.h
> > @@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore 
> > *sem)
> >  # define __RWSEM_DEP_MAP_INIT(lockname)
> >  #endif
> >  
> > -#ifdef CONFIG_SMP
> > +#if defined(CONFIG_SMP) && defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
> >  #define __RWSEM_INITIALIZER(name)  \
> > { RWSEM_UNLOCKED_VALUE, \
> >   __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \
> 
> that squishes the warnings for me.

You guys know best, but shouldn't this change be routed through -tip?


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

Re: linux-next: build warning after merge of the akpm tree

[Andrew Morton]

On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso  wrote:

> > Presumably a result of commit fe2038c57c03 ("rwsem: Support optimistic
> > spinning").
> 
> If CONFIG_SMP, we add two new fields to the rwsem structure
> (include/linux/rwsem.h) and likewise we update the
> __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
> something like that is to be using the spinlock variant
> (rwsem-spinlock.h).
> 
> The fix for that would be:
> 
> diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
> index 3e108f1..091d993 100644
> --- a/include/linux/rwsem.h
> +++ b/include/linux/rwsem.h
> @@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
>  # define __RWSEM_DEP_MAP_INIT(lockname)
>  #endif
>  
> -#ifdef CONFIG_SMP
> +#if defined(CONFIG_SMP) && defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
>  #define __RWSEM_INITIALIZER(name)  \
> { RWSEM_UNLOCKED_VALUE, \
>   __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \

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

Re: linux-next: build warning after merge of the akpm tree

[Davidlohr Bueso]

Hi Stephen,

On Mon, 2014-05-19 at 18:13 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
> 
> 
> ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
> [enabled by default]
> ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
> 'ipcns_chain.rwsem') [enabled by default]
> ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
> [enabled by default]
> ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
> 'ipcns_chain.rwsem') [enabled by default]
> 
> and many more in other files ...

Hmm are all the warning the same? Is this just on arm? have you seen it
in other archs? (Could you please send me the .config)

> Presumably a result of commit fe2038c57c03 ("rwsem: Support optimistic
> spinning").

If CONFIG_SMP, we add two new fields to the rwsem structure
(include/linux/rwsem.h) and likewise we update the
__RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
something like that is to be using the spinlock variant
(rwsem-spinlock.h).

The fix for that would be:

diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 3e108f1..091d993 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
 # define __RWSEM_DEP_MAP_INIT(lockname)
 #endif
 
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
 #define __RWSEM_INITIALIZER(name)  \
{ RWSEM_UNLOCKED_VALUE, \
  __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \



> I reverted that commit (and
> "rwsem-support-optimistic-spinning-checkpatch-fixes") for today.

This was picked up today by -tip maintainers, so I guess it should also
be removed from -mm.

Thanks,
Davidlohr


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

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:


ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
[enabled by default]
ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
'ipcns_chain.rwsem') [enabled by default]
ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
[enabled by default]
ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
'ipcns_chain.rwsem') [enabled by default]

and many more in other files ...

Presumably a result of commit fe2038c57c03 ("rwsem: Support optimistic
spinning").

I reverted that commit (and
"rwsem-support-optimistic-spinning-checkpatch-fixes") for today.

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


signature.asc
Description: PGP signature

Re: linux-next: build warning after merge of the akpm tree

[Andrew Morton]

On Mon, 19 May 2014 13:56:20 -0700 Davidlohr Bueso davidl...@hp.com wrote:

 On Mon, 2014-05-19 at 12:48 -0700, Andrew Morton wrote:
  On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso davidl...@hp.com wrote:
  
Presumably a result of commit fe2038c57c03 (rwsem: Support optimistic
spinning).
   
   If CONFIG_SMP, we add two new fields to the rwsem structure
   (include/linux/rwsem.h) and likewise we update the
   __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
   something like that is to be using the spinlock variant
   (rwsem-spinlock.h).
   
   The fix for that would be:
   
   diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
   index 3e108f1..091d993 100644
   --- a/include/linux/rwsem.h
   +++ b/include/linux/rwsem.h
   @@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore 
   *sem)
# define __RWSEM_DEP_MAP_INIT(lockname)
#endif

   -#ifdef CONFIG_SMP
   +#if defined(CONFIG_SMP)  defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
#define __RWSEM_INITIALIZER(name)  \
   { RWSEM_UNLOCKED_VALUE, \
 __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \
  
  that squishes the warnings for me.
 
 You guys know best, but shouldn't this change be routed through -tip?

Yes, this patch and the two fixes I have applied to it should be sent
that way.  If/when they turn up in -next I will drop my copies.

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

Re: linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi,

On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso davidl...@hp.com wrote:

 On Mon, 2014-05-19 at 18:13 +1000, Stephen Rothwell wrote:
  Hi Andrew,
  
  After merging the akpm tree, today's linux-next build (arm
  multi_v7_defconfig) produced these warnings:
  
  
  ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
  [enabled by default]
  ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
  'ipcns_chain.rwsem') [enabled by default]
  ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
  [enabled by default]
  ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
  'ipcns_chain.rwsem') [enabled by default]
  
  and many more in other files ...
 
 Hmm are all the warning the same? Is this just on arm? have you seen it
 in other archs? (Could you please send me the .config)

The warnings were all the same, I saw it only on arm (since that was
what I built) and I mentioned the config above.

  Presumably a result of commit fe2038c57c03 (rwsem: Support optimistic
  spinning).
 
 If CONFIG_SMP, we add two new fields to the rwsem structure
 (include/linux/rwsem.h) and likewise we update the
 __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
 something like that is to be using the spinlock variant
 (rwsem-spinlock.h).

Actually quite a few architectures do set
CONFIG_RWSEM_GENERIC_SPINLOCK, and so wouldn't it make more sense to
actually directly test that?

 The fix for that would be:
 
 diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
 index 3e108f1..091d993 100644
 --- a/include/linux/rwsem.h
 +++ b/include/linux/rwsem.h
 @@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
  # define __RWSEM_DEP_MAP_INIT(lockname)
  #endif
  
 -#ifdef CONFIG_SMP
 +#if defined(CONFIG_SMP)  defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)

so

#if defined(CONFIG_SMP)  !defined(CONFIG_RWSEM_GENERIC_SPINLOCK)

?

 This was picked up today by -tip maintainers, so I guess it should also
 be removed from -mm.

Was a fix also picked up?

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


signature.asc
Description: PGP signature

Re: linux-next: build warning after merge of the akpm tree

[Davidlohr Bueso]

On Tue, 2014-05-20 at 07:36 +1000, Stephen Rothwell wrote:
 Hi,
 
 On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso davidl...@hp.com wrote:
 
  On Mon, 2014-05-19 at 18:13 +1000, Stephen Rothwell wrote:
   Hi Andrew,
   
   After merging the akpm tree, today's linux-next build (arm
   multi_v7_defconfig) produced these warnings:
   
   
   ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
   [enabled by default]
   ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
   'ipcns_chain.rwsem') [enabled by default]
   ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
   [enabled by default]
   ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
   'ipcns_chain.rwsem') [enabled by default]
   
   and many more in other files ...
  
  Hmm are all the warning the same? Is this just on arm? have you seen it
  in other archs? (Could you please send me the .config)
 
 The warnings were all the same, I saw it only on arm (since that was
 what I built) and I mentioned the config above.
 
   Presumably a result of commit fe2038c57c03 (rwsem: Support optimistic
   spinning).
  
  If CONFIG_SMP, we add two new fields to the rwsem structure
  (include/linux/rwsem.h) and likewise we update the
  __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
  something like that is to be using the spinlock variant
  (rwsem-spinlock.h).
 
 Actually quite a few architectures do set
 CONFIG_RWSEM_GENERIC_SPINLOCK, and so wouldn't it make more sense to
 actually directly test that?

Both are equivalent, I have no preference. I've sent a formal fix to the
-tip folks, I guess I'll let them choose.

Thanks,
Davidlohr

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

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:


ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
[enabled by default]
ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
'ipcns_chain.rwsem') [enabled by default]
ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
[enabled by default]
ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
'ipcns_chain.rwsem') [enabled by default]

and many more in other files ...

Presumably a result of commit fe2038c57c03 (rwsem: Support optimistic
spinning).

I reverted that commit (and
rwsem-support-optimistic-spinning-checkpatch-fixes) for today.

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


signature.asc
Description: PGP signature

Re: linux-next: build warning after merge of the akpm tree

[Davidlohr Bueso]

Hi Stephen,

On Mon, 2014-05-19 at 18:13 +1000, Stephen Rothwell wrote:
 Hi Andrew,
 
 After merging the akpm tree, today's linux-next build (arm
 multi_v7_defconfig) produced these warnings:
 
 
 ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
 [enabled by default]
 ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
 'ipcns_chain.rwsem') [enabled by default]
 ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer 
 [enabled by default]
 ipc/ipcns_notifier.c:22:8: warning: (near initialization for 
 'ipcns_chain.rwsem') [enabled by default]
 
 and many more in other files ...

Hmm are all the warning the same? Is this just on arm? have you seen it
in other archs? (Could you please send me the .config)

 Presumably a result of commit fe2038c57c03 (rwsem: Support optimistic
 spinning).

If CONFIG_SMP, we add two new fields to the rwsem structure
(include/linux/rwsem.h) and likewise we update the
__RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
something like that is to be using the spinlock variant
(rwsem-spinlock.h).

The fix for that would be:

diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 3e108f1..091d993 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
 # define __RWSEM_DEP_MAP_INIT(lockname)
 #endif
 
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP)  defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
 #define __RWSEM_INITIALIZER(name)  \
{ RWSEM_UNLOCKED_VALUE, \
  __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \



 I reverted that commit (and
 rwsem-support-optimistic-spinning-checkpatch-fixes) for today.

This was picked up today by -tip maintainers, so I guess it should also
be removed from -mm.

Thanks,
Davidlohr


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

Re: linux-next: build warning after merge of the akpm tree

[Andrew Morton]

On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso davidl...@hp.com wrote:

  Presumably a result of commit fe2038c57c03 (rwsem: Support optimistic
  spinning).
 
 If CONFIG_SMP, we add two new fields to the rwsem structure
 (include/linux/rwsem.h) and likewise we update the
 __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
 something like that is to be using the spinlock variant
 (rwsem-spinlock.h).
 
 The fix for that would be:
 
 diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
 index 3e108f1..091d993 100644
 --- a/include/linux/rwsem.h
 +++ b/include/linux/rwsem.h
 @@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
  # define __RWSEM_DEP_MAP_INIT(lockname)
  #endif
  
 -#ifdef CONFIG_SMP
 +#if defined(CONFIG_SMP)  defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
  #define __RWSEM_INITIALIZER(name)  \
 { RWSEM_UNLOCKED_VALUE, \
   __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \

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

Re: linux-next: build warning after merge of the akpm tree

[Davidlohr Bueso]

On Mon, 2014-05-19 at 12:48 -0700, Andrew Morton wrote:
 On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso davidl...@hp.com wrote:
 
   Presumably a result of commit fe2038c57c03 (rwsem: Support optimistic
   spinning).
  
  If CONFIG_SMP, we add two new fields to the rwsem structure
  (include/linux/rwsem.h) and likewise we update the
  __RWSEM_INITIALIZER(name) macro. Afaict the only way to trigger
  something like that is to be using the spinlock variant
  (rwsem-spinlock.h).
  
  The fix for that would be:
  
  diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
  index 3e108f1..091d993 100644
  --- a/include/linux/rwsem.h
  +++ b/include/linux/rwsem.h
  @@ -64,7 +64,7 @@ static inline int rwsem_is_locked(struct rw_semaphore 
  *sem)
   # define __RWSEM_DEP_MAP_INIT(lockname)
   #endif
   
  -#ifdef CONFIG_SMP
  +#if defined(CONFIG_SMP)  defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
   #define __RWSEM_INITIALIZER(name)  \
  { RWSEM_UNLOCKED_VALUE, \
__RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \
 
 that squishes the warnings for me.

You guys know best, but shouldn't this change be routed through -tip?


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

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

fs/fat/inode.c: In function 'fat_zero_falloc_area':
fs/fat/inode.c:170:11: warning: comparison of distinct pointer types lacks a 
cast [enabled by default]

Introduced by commit "fat: additions to support fat_fallocate".

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


pgpotR4dm32PG.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

fs/fat/inode.c: In function 'fat_zero_falloc_area':
fs/fat/inode.c:170:11: warning: comparison of distinct pointer types lacks a 
cast [enabled by default]

Introduced by commit fat: additions to support fat_fallocate.

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


pgpotR4dm32PG.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

ipc/util.c: In function 'ipc_init':
ipc/util.c:105:2: warning: statement with no effect [-Wunused-value]
mm/slub.c: In function 'kmem_cache_init':
mm/slub.c:3600:2: warning: statement with no effect [-Wunused-value]

Introduced by commit 23e9e430f87e ("include/linux/memory.h: implement
register_hotmemory_notifier()").

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


pgpGwZEvOMjd4.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

include/linux/genalloc.h:109:3: warning: 'struct device' declared inside 
parameter list [enabled by default]
include/linux/genalloc.h:109:3: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
include/linux/genalloc.h:110:49: warning: 'struct device' declared inside 
parameter list [enabled by default]

Introduced by commit 3f364a866cf1 ("genalloc: add devres support, allow
to find a managed pool by device")
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgps6SbjvxAUl.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

include/linux/genalloc.h:109:3: warning: 'struct device' declared inside 
parameter list [enabled by default]
include/linux/genalloc.h:109:3: warning: its scope is only this definition or 
declaration, which is probably not what you want [enabled by default]
include/linux/genalloc.h:110:49: warning: 'struct device' declared inside 
parameter list [enabled by default]

Introduced by commit 3f364a866cf1 (genalloc: add devres support, allow
to find a managed pool by device)
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgps6SbjvxAUl.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

ipc/util.c: In function 'ipc_init':
ipc/util.c:105:2: warning: statement with no effect [-Wunused-value]
mm/slub.c: In function 'kmem_cache_init':
mm/slub.c:3600:2: warning: statement with no effect [-Wunused-value]

Introduced by commit 23e9e430f87e (include/linux/memory.h: implement
register_hotmemory_notifier()).

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


pgpGwZEvOMjd4.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Peter Jones]

Stephen,

The following email is an updated patch which should fix the warning you're
seeing on architectures where sizeof is unsigned int rather than unsigned
long.

This completely replaces the ef25bb0fa6e2 patch.  Andrew, if you'd prefer a
single-line fixup patch, I can send you that instead.


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

linux-next: build warning after merge of the akpm tree

[Peter Jones]

Stephen,

The following email is an updated patch which should fix the warning you're
seeing on architectures where sizeof is unsigned int rather than unsigned
long.

This completely replaces the ef25bb0fa6e2 patch.  Andrew, if you'd prefer a
single-line fixup patch, I can send you that instead.


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

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

block/partitions/efi.c: In function 'is_gpt_valid':
block/partitions/efi.c:324:3: warning: format '%lu' expects argument of type 
'long unsigned int', but argument 3 has type 'unsigned int' [-Wformat]

Introduced by commit ef25bb0fa6e2 ("block/partitions/efi.c: ensure that
the GPT header is at least the size of the structure").
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpTTipSJ6gHM.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

block/partitions/efi.c: In function 'is_gpt_valid':
block/partitions/efi.c:324:3: warning: format '%lu' expects argument of type 
'long unsigned int', but argument 3 has type 'unsigned int' [-Wformat]

Introduced by commit ef25bb0fa6e2 (block/partitions/efi.c: ensure that
the GPT header is at least the size of the structure).
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpTTipSJ6gHM.pgp
Description: PGP signature

Re: linux-next: build warning after merge of the akpm tree

[Tang Chen]

On 01/23/2013 02:33 PM, Stephen Rothwell wrote:

Hi Andrew,

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

mm/page_alloc.c:4477:23: warning: 'sanitize_zone_movable_limit' defined but not 
used [-Wunused-function]

Introduced by commit "page_alloc: introduce zone_movable_limit[] to keep
movable limit for nodes" from the akpm tree.  It is defined both when
CONFIG_HAVE_MEMBLOCK_NODE_MAP is defined and not, but only used if it is
defined.



Hi Stephen,

Thank you for reporting this. :)

I was aware of this problem by the kbuild rebot, and I think this 
problem has been fixed
by the following patch I sent yesterday, and merged into -mm tree this 
morning.


Since I could access the lkml web site today, I cannot get an url for you.
Please tell me if your problem is not solved after applying this patch. :)

Thanks. :)


[PATCH Bug fix 3/4] Bug fix: Remove the unused 
sanitize_zone_movable_limit() definition.


When CONFIG_HAVE_MEMBLOCK_NODE_MAP is not defined, 
sanitize_zone_movable_limit()

is also not used. So remove it.

Signed-off-by: Tang Chen 
---
 mm/page_alloc.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cd6f8a6..2bd529e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4459,11 +4459,6 @@ static inline unsigned long __meminit 
zone_absent_pages_in_node(int nid,


return zholes_size[zone_type];
 }
-
-static void __meminit sanitize_zone_movable_limit(void)
-{
-}
-
 #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */

 static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
-- 1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

mm/page_alloc.c:4477:23: warning: 'sanitize_zone_movable_limit' defined but not 
used [-Wunused-function]

Introduced by commit "page_alloc: introduce zone_movable_limit[] to keep
movable limit for nodes" from the akpm tree.  It is defined both when
CONFIG_HAVE_MEMBLOCK_NODE_MAP is defined and not, but only used if it is
defined.

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


pgpWEK2QHBF8b.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

mm/page_alloc.c:4477:23: warning: 'sanitize_zone_movable_limit' defined but not 
used [-Wunused-function]

Introduced by commit page_alloc: introduce zone_movable_limit[] to keep
movable limit for nodes from the akpm tree.  It is defined both when
CONFIG_HAVE_MEMBLOCK_NODE_MAP is defined and not, but only used if it is
defined.

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


pgpWEK2QHBF8b.pgp
Description: PGP signature

Re: linux-next: build warning after merge of the akpm tree

[Tang Chen]

On 01/23/2013 02:33 PM, Stephen Rothwell wrote:

Hi Andrew,

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

mm/page_alloc.c:4477:23: warning: 'sanitize_zone_movable_limit' defined but not 
used [-Wunused-function]

Introduced by commit page_alloc: introduce zone_movable_limit[] to keep
movable limit for nodes from the akpm tree.  It is defined both when
CONFIG_HAVE_MEMBLOCK_NODE_MAP is defined and not, but only used if it is
defined.



Hi Stephen,

Thank you for reporting this. :)

I was aware of this problem by the kbuild rebot, and I think this 
problem has been fixed
by the following patch I sent yesterday, and merged into -mm tree this 
morning.


Since I could access the lkml web site today, I cannot get an url for you.
Please tell me if your problem is not solved after applying this patch. :)

Thanks. :)


[PATCH Bug fix 3/4] Bug fix: Remove the unused 
sanitize_zone_movable_limit() definition.


When CONFIG_HAVE_MEMBLOCK_NODE_MAP is not defined, 
sanitize_zone_movable_limit()

is also not used. So remove it.

Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
---
 mm/page_alloc.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cd6f8a6..2bd529e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4459,11 +4459,6 @@ static inline unsigned long __meminit 
zone_absent_pages_in_node(int nid,


return zholes_size[zone_type];
 }
-
-static void __meminit sanitize_zone_movable_limit(void)
-{
-}
-
 #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */

 static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
-- 1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build warning after merge of the akpm tree

[Grant Likely]

On Fri, Nov 9, 2012 at 3:43 AM, Stephen Rothwell  wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> allnoconfig - among others) produced this warning:
>
> drivers/of/fdt.c: In function 'of_scan_flat_dt':
> drivers/of/fdt.c:490:10: warning: assignment discards 'const' qualifier from 
> pointer target type [enabled by default]
>
> Introduced by commit "drivers/of/fdt.c: re-use kernel's kbasename()".

Adding this hunk to the patch fixes it:

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 91a375f..738228f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -459,7 +459,7 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,

do {
u32 tag = be32_to_cpup((__be32 *)p);
-   char *pathp;
+   const char *pathp;

p += 4;
if (tag == OF_DT_END_NODE) {

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

Re: linux-next: build warning after merge of the akpm tree

[Grant Likely]

On Fri, Nov 9, 2012 at 3:43 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi Andrew,

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

 drivers/of/fdt.c: In function 'of_scan_flat_dt':
 drivers/of/fdt.c:490:10: warning: assignment discards 'const' qualifier from 
 pointer target type [enabled by default]

 Introduced by commit drivers/of/fdt.c: re-use kernel's kbasename().

Adding this hunk to the patch fixes it:

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 91a375f..738228f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -459,7 +459,7 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,

do {
u32 tag = be32_to_cpup((__be32 *)p);
-   char *pathp;
+   const char *pathp;

p += 4;
if (tag == OF_DT_END_NODE) {

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

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

drivers/of/fdt.c: In function 'of_scan_flat_dt':
drivers/of/fdt.c:490:10: warning: assignment discards 'const' qualifier from 
pointer target type [enabled by default]

Introduced by commit "drivers/of/fdt.c: re-use kernel's kbasename()".

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


pgpFuoOGL6PFo.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

drivers/of/fdt.c: In function 'of_scan_flat_dt':
drivers/of/fdt.c:490:10: warning: assignment discards 'const' qualifier from 
pointer target type [enabled by default]

Introduced by commit drivers/of/fdt.c: re-use kernel's kbasename().

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


pgpFuoOGL6PFo.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

mm/rmap.c: In function 'try_to_unmap_cluster':
mm/rmap.c:1364:9: warning: unused variable 'pud' [-Wunused-variable]
mm/rmap.c:1363:9: warning: unused variable 'pgd' [-Wunused-variable]

Introduced by commit "mm: introduce mm_find_pmd()".
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpJ5EU608SiV.pgp
Description: PGP signature

linux-next: build warning after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

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

mm/rmap.c: In function 'try_to_unmap_cluster':
mm/rmap.c:1364:9: warning: unused variable 'pud' [-Wunused-variable]
mm/rmap.c:1363:9: warning: unused variable 'pgd' [-Wunused-variable]

Introduced by commit mm: introduce mm_find_pmd().
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpJ5EU608SiV.pgp
Description: PGP signature