linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: build warning after merge of the akpm tree
@ 2014-05-19  8:13 Stephen Rothwell
  2014-05-19 15:13 ` Davidlohr Bueso
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2014-05-19  8:13 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Davidlohr Bueso, Tim Chen

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

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 Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2014-05-19  8:13 linux-next: build warning after merge of the akpm tree Stephen Rothwell
@ 2014-05-19 15:13 ` Davidlohr Bueso
  2014-05-19 19:48   ` Andrew Morton
  2014-05-19 21:36   ` Stephen Rothwell
  0 siblings, 2 replies; 51+ messages in thread
From: Davidlohr Bueso @ 2014-05-19 15:13 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Tim Chen

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2014-05-19 15:13 ` Davidlohr Bueso
@ 2014-05-19 19:48   ` Andrew Morton
  2014-05-19 20:56     ` Davidlohr Bueso
  2014-05-19 21:36   ` Stephen Rothwell
  1 sibling, 1 reply; 51+ messages in thread
From: Andrew Morton @ 2014-05-19 19:48 UTC (permalink / raw)
  To: Davidlohr Bueso; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tim Chen

On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso <davidlohr@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.

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

* Re: linux-next: build warning after merge of the akpm tree
  2014-05-19 19:48   ` Andrew Morton
@ 2014-05-19 20:56     ` Davidlohr Bueso
  2014-05-19 21:17       ` Andrew Morton
  0 siblings, 1 reply; 51+ messages in thread
From: Davidlohr Bueso @ 2014-05-19 20:56 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tim Chen

On Mon, 2014-05-19 at 12:48 -0700, Andrew Morton wrote:
> On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso <davidlohr@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?

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

* Re: linux-next: build warning after merge of the akpm tree
  2014-05-19 20:56     ` Davidlohr Bueso
@ 2014-05-19 21:17       ` Andrew Morton
  0 siblings, 0 replies; 51+ messages in thread
From: Andrew Morton @ 2014-05-19 21:17 UTC (permalink / raw)
  To: Davidlohr Bueso; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tim Chen

On Mon, 19 May 2014 13:56:20 -0700 Davidlohr Bueso <davidlohr@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 <davidlohr@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 ;)

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

* Re: linux-next: build warning after merge of the akpm tree
  2014-05-19 15:13 ` Davidlohr Bueso
  2014-05-19 19:48   ` Andrew Morton
@ 2014-05-19 21:36   ` Stephen Rothwell
  2014-05-19 22:38     ` Davidlohr Bueso
  1 sibling, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2014-05-19 21:36 UTC (permalink / raw)
  To: Davidlohr Bueso; +Cc: Andrew Morton, linux-next, linux-kernel, Tim Chen

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

Hi,

On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso <davidlohr@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 Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2014-05-19 21:36   ` Stephen Rothwell
@ 2014-05-19 22:38     ` Davidlohr Bueso
  0 siblings, 0 replies; 51+ messages in thread
From: Davidlohr Bueso @ 2014-05-19 22:38 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Tim Chen

On Tue, 2014-05-20 at 07:36 +1000, Stephen Rothwell wrote:
> Hi,
> 
> On Mon, 19 May 2014 08:13:16 -0700 Davidlohr Bueso <davidlohr@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

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

* Re: linux-next: build warning after merge of the akpm tree
  2021-01-28  8:46 Stephen Rothwell
@ 2021-02-01  7:14 ` Vijayanand Jitta
  0 siblings, 0 replies; 51+ messages in thread
From: Vijayanand Jitta @ 2021-02-01  7:14 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Vinayak Menon, Linux Kernel Mailing List, Linux Next Mailing List



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, &stack_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 <vjitta@codeaurora.org>

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 <vjitta@codeaurora.org>
---
 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, &stack_depot_disable);
-	if (stack_depot_disable) {
+	int ret;
+
+	ret = kstrtobool(str, &stack_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

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

* linux-next: build warning after merge of the akpm tree
@ 2021-01-28  8:46 Stephen Rothwell
  2021-02-01  7:14 ` Vijayanand Jitta
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2021-01-28  8:46 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Vijayanand Jitta, Vinayak Menon, Linux Kernel Mailing List,
	Linux Next Mailing List

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

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, &stack_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

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-10  0:19       ` Michael Ellerman
@ 2020-12-10 21:17         ` Stephen Rothwell
  0 siblings, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2020-12-10 21:17 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List, Kees Cook, PowerPC, Mathieu Malaterre,
	Nicholas Piggin

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

Hi Michael,

On Thu, 10 Dec 2020 11:19:45 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> >
> > On Wed, 09 Dec 2020 15:44:35 +1100 Michael Ellerman <mpe@ellerman.id.au> 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

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-09  7:07     ` Stephen Rothwell
@ 2020-12-10  0:19       ` Michael Ellerman
  2020-12-10 21:17         ` Stephen Rothwell
  0 siblings, 1 reply; 51+ messages in thread
From: Michael Ellerman @ 2020-12-10  0:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List, Kees Cook, PowerPC, Mathieu Malaterre,
	Nicholas Piggin

Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Michael,
>
> On Wed, 09 Dec 2020 15:44:35 +1100 Michael Ellerman <mpe@ellerman.id.au> 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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-08 12:01 ` Stephen Rothwell
  2020-12-09  4:44   ` Michael Ellerman
  2020-12-09 10:33   ` Stephen Rothwell
@ 2020-12-09 18:56   ` Kees Cook
  2 siblings, 0 replies; 51+ messages in thread
From: Kees Cook @ 2020-12-09 18:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List, Michael Ellerman, PowerPC,
	Mathieu Malaterre, Nicholas Piggin

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 <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>
> ---
>  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 <keescook@chromium.org>

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-08 12:01 ` Stephen Rothwell
  2020-12-09  4:44   ` Michael Ellerman
@ 2020-12-09 10:33   ` Stephen Rothwell
  2020-12-09 18:56   ` Kees Cook
  2 siblings, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2020-12-09 10:33 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Kees Cook,
	Michael Ellerman, PowerPC, Mathieu Malaterre, Nicholas Piggin

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

Hi all,

On Tue, 8 Dec 2020 23:01:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I will try the following patch tomorrow:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>
> ---
>  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

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-07 12:52       ` Marco Elver
@ 2020-12-09 10:06         ` Dmitry Vyukov
  0 siblings, 0 replies; 51+ messages in thread
From: Dmitry Vyukov @ 2020-12-09 10:06 UTC (permalink / raw)
  To: Marco Elver
  Cc: Andrew Morton, Stephen Rothwell, Linux Kernel Mailing List,
	Linux Next Mailing List, Alexander Potapenko, Andrey Konovalov,
	kasan-dev, Kees Cook

On Mon, Dec 7, 2020 at 1:52 PM Marco Elver <elver@google.com> wrote:
>
> On Mon, 7 Dec 2020 at 13:38, 'Dmitry Vyukov' via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
> > On Mon, Dec 7, 2020 at 1:08 PM Dmitry Vyukov <dvyukov@google.com> 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-dvyukov@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.

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-09  4:44   ` Michael Ellerman
@ 2020-12-09  7:07     ` Stephen Rothwell
  2020-12-10  0:19       ` Michael Ellerman
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2020-12-09  7:07 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List, Kees Cook, PowerPC, Mathieu Malaterre,
	Nicholas Piggin

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

Hi Michael,

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

No other architecture appears t need them ...

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-08 12:01 ` Stephen Rothwell
@ 2020-12-09  4:44   ` Michael Ellerman
  2020-12-09  7:07     ` Stephen Rothwell
  2020-12-09 10:33   ` Stephen Rothwell
  2020-12-09 18:56   ` Kees Cook
  2 siblings, 1 reply; 51+ messages in thread
From: Michael Ellerman @ 2020-12-09  4:44 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Kees Cook,
	PowerPC, Mathieu Malaterre, Nicholas Piggin

Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Stephen,
>
> On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-04 10:00 Stephen Rothwell
  2020-12-05  5:19 ` Andrew Morton
@ 2020-12-08 12:01 ` Stephen Rothwell
  2020-12-09  4:44   ` Michael Ellerman
                     ` (2 more replies)
  1 sibling, 3 replies; 51+ messages in thread
From: Stephen Rothwell @ 2020-12-08 12:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Kees Cook,
	Michael Ellerman, PowerPC, Mathieu Malaterre, Nicholas Piggin

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

Hi Stephen,

On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-07 12:38     ` Dmitry Vyukov
@ 2020-12-07 12:52       ` Marco Elver
  2020-12-09 10:06         ` Dmitry Vyukov
  0 siblings, 1 reply; 51+ messages in thread
From: Marco Elver @ 2020-12-07 12:52 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Andrew Morton, Stephen Rothwell, Linux Kernel Mailing List,
	Linux Next Mailing List, Alexander Potapenko, Andrey Konovalov,
	kasan-dev, Kees Cook

On Mon, 7 Dec 2020 at 13:38, 'Dmitry Vyukov' via kasan-dev
<kasan-dev@googlegroups.com> wrote:
> On Mon, Dec 7, 2020 at 1:08 PM Dmitry Vyukov <dvyukov@google.com> 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.

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-07 12:08   ` Dmitry Vyukov
@ 2020-12-07 12:38     ` Dmitry Vyukov
  2020-12-07 12:52       ` Marco Elver
  0 siblings, 1 reply; 51+ messages in thread
From: Dmitry Vyukov @ 2020-12-07 12:38 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux Kernel Mailing List,
	Linux Next Mailing List, Alexander Potapenko, Andrey Konovalov,
	kasan-dev, Kees Cook

On Mon, Dec 7, 2020 at 1:08 PM Dmitry Vyukov <dvyukov@google.com> 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.

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-05  5:19 ` Andrew Morton
  2020-12-05  9:37   ` Stephen Rothwell
@ 2020-12-07 12:08   ` Dmitry Vyukov
  2020-12-07 12:38     ` Dmitry Vyukov
  1 sibling, 1 reply; 51+ messages in thread
From: Dmitry Vyukov @ 2020-12-07 12:08 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux Kernel Mailing List,
	Linux Next Mailing List, Alexander Potapenko, Andrey Konovalov,
	kasan-dev, Kees Cook

On Sat, Dec 5, 2020 at 6:19 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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)

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-05  5:19 ` Andrew Morton
@ 2020-12-05  9:37   ` Stephen Rothwell
  2020-12-07 12:08   ` Dmitry Vyukov
  1 sibling, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2020-12-05  9:37 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Victor Chibotaru, Alexander Potapenko, Dmitry Vyukov,
	Andrey Konovalov

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

Hi Andrew,

On Fri, 4 Dec 2020 21:19:23 -0800 Andrew Morton <akpm@linux-foundation.org> 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

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-12-04 10:00 Stephen Rothwell
@ 2020-12-05  5:19 ` Andrew Morton
  2020-12-05  9:37   ` Stephen Rothwell
  2020-12-07 12:08   ` Dmitry Vyukov
  2020-12-08 12:01 ` Stephen Rothwell
  1 sibling, 2 replies; 51+ messages in thread
From: Andrew Morton @ 2020-12-05  5:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Victor Chibotaru, Alexander Potapenko, Dmitry Vyukov,
	Andrey Konovalov

On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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.


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

* linux-next: build warning after merge of the akpm tree
@ 2020-12-04 10:00 Stephen Rothwell
  2020-12-05  5:19 ` Andrew Morton
  2020-12-08 12:01 ` Stephen Rothwell
  0 siblings, 2 replies; 51+ messages in thread
From: Stephen Rothwell @ 2020-12-04 10:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-02-28  4:35 Stephen Rothwell
@ 2020-02-28  5:23 ` Arjun Roy
  0 siblings, 0 replies; 51+ messages in thread
From: Arjun Roy @ 2020-02-28  5:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On Thu, Feb 27, 2020 at 8:35 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm tree, today's linux-next build (sparc defconfig)
> produced this warning:
>
> mm/memory.c:1463:12: warning: 'insert_page_in_batch_locked' defined but not used [-Wunused-function]
>  static int insert_page_in_batch_locked(struct mm_struct *mm, pmd_t *pmd,
>             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Well, that's certainly a step in the right direction if it compiles :)

I guess having this function be within the ifdef is the way to make
this warning go away.

I'll, er, make a v3 patch.

-Arjun

> Introduced by commit
>
>   4a879e02dd49 ("mm/memory.c: add vm_insert_pages()")
>
> --
> Cheers,
> Stephen Rothwell

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

* linux-next: build warning after merge of the akpm tree
@ 2020-02-28  4:35 Stephen Rothwell
  2020-02-28  5:23 ` Arjun Roy
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2020-02-28  4:35 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Arjun Roy

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

Hi all,

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

mm/memory.c:1463:12: warning: 'insert_page_in_batch_locked' defined but not used [-Wunused-function]
 static int insert_page_in_batch_locked(struct mm_struct *mm, pmd_t *pmd,
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~

Introduced by commit

  4a879e02dd49 ("mm/memory.c: add vm_insert_pages()")

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2020-01-07 23:11 ` Andrew Morton
@ 2020-01-08 14:52   ` Steven Price
  0 siblings, 0 replies; 51+ messages in thread
From: Steven Price @ 2020-01-08 14:52 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List

On Tue, Jan 07, 2020 at 11:11:07PM +0000, Andrew Morton wrote:
> On Mon, 6 Jan 2020 17:07:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the akpm tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> > 
> > arch/x86/mm/dump_pagetables.c: In function 'ptdump_walk_pgd_level_core':
> > arch/x86/mm/dump_pagetables.c:403:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> >   403 | }
> >       | ^
> > 
> > Introduced by commit
> > 
> >   710fae4f03f2 ("x86: mm: convert dump_pagetables to use walk_page_range")
> > 
> 
> (gdb) p sizeof(struct mm_struct)
> $1 = 1664
> 
> yup, that'll do it.

Ok, looks like I'll have to do something a little bit more clever than
the "fake_mm" hack I used before. The trouble is x86 now has two PGDs
due to the PAGE_TABLE_ISOLATION feature. I was trying to isolate this
quirk to the x86 code, but it looks like we need some way of passing an
"override" down for the PGD.

I'll post a possible fix as a reply to this post.

Steve


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

* Re: linux-next: build warning after merge of the akpm tree
  2020-01-06  6:07 Stephen Rothwell
@ 2020-01-07 23:11 ` Andrew Morton
  2020-01-08 14:52   ` Steven Price
  0 siblings, 1 reply; 51+ messages in thread
From: Andrew Morton @ 2020-01-07 23:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Steven Price

On Mon, 6 Jan 2020 17:07:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> arch/x86/mm/dump_pagetables.c: In function 'ptdump_walk_pgd_level_core':
> arch/x86/mm/dump_pagetables.c:403:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>   403 | }
>       | ^
> 
> Introduced by commit
> 
>   710fae4f03f2 ("x86: mm: convert dump_pagetables to use walk_page_range")
> 

(gdb) p sizeof(struct mm_struct)
$1 = 1664

yup, that'll do it.



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

* linux-next: build warning after merge of the akpm tree
@ 2020-01-06  6:11 Stephen Rothwell
  0 siblings, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2020-01-06  6:11 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Steven Price

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

Hi all,

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

mm/hmm.c: In function 'hmm_vma_walk_pud':
mm/hmm.c:478:9: warning: unused variable 'pmdp' [-Wunused-variable]
  478 |  pmd_t *pmdp;
      |         ^~~~
mm/hmm.c:477:30: warning: unused variable 'next' [-Wunused-variable]
  477 |  unsigned long addr = start, next;
      |                              ^~~~

Introduced by commit

  cc53bfffefc3 ("mm: pagewalk: add p4d_entry() and pgd_entry()")

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build warning after merge of the akpm tree
@ 2020-01-06  6:07 Stephen Rothwell
  2020-01-07 23:11 ` Andrew Morton
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2020-01-06  6:07 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Steven Price

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

Hi all,

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

arch/x86/mm/dump_pagetables.c: In function 'ptdump_walk_pgd_level_core':
arch/x86/mm/dump_pagetables.c:403:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
  403 | }
      | ^

Introduced by commit

  710fae4f03f2 ("x86: mm: convert dump_pagetables to use walk_page_range")

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2018-11-30  5:40 Stephen Rothwell
@ 2018-11-30 14:52 ` Dave Rodgman
  0 siblings, 0 replies; 51+ messages in thread
From: Dave Rodgman @ 2018-11-30 14:52 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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.

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

* linux-next: build warning after merge of the akpm tree
@ 2018-11-30  5:40 Stephen Rothwell
  2018-11-30 14:52 ` Dave Rodgman
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2018-11-30  5:40 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Dave Rodgman

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

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

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2017-08-01  6:15 ` Huang, Ying
@ 2017-08-01 21:15   ` Arnd Bergmann
  0 siblings, 0 replies; 51+ messages in thread
From: Arnd Bergmann @ 2017-08-01 21:15 UTC (permalink / raw)
  To: Huang, Ying
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Tue, Aug 1, 2017 at 8:15 AM, Huang, Ying <ying.huang@intel.com> wrote:
> From 7a7ff76d7bcbd7affda169b29abcf3dafa38052e Mon Sep 17 00:00:00 2001
> From: Huang Ying <ying.huang@intel.com>
> 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

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

* Re: linux-next: build warning after merge of the akpm tree
  2017-08-01  6:02 Stephen Rothwell
@ 2017-08-01  6:15 ` Huang, Ying
  2017-08-01 21:15   ` Arnd Bergmann
  0 siblings, 1 reply; 51+ messages in thread
From: Huang, Ying @ 2017-08-01  6:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Huang Ying

Hi, Stephen,

Thanks for reporting.

Stephen Rothwell <sfr@canb.auug.org.au> 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 <ying.huang@intel.com>
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 <sfr@canb.auug.org.au>
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
---
 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

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

* linux-next: build warning after merge of the akpm tree
@ 2017-08-01  6:02 Stephen Rothwell
  2017-08-01  6:15 ` Huang, Ying
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2017-08-01  6:02 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Huang Ying

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2017-06-26  6:30 Stephen Rothwell
@ 2017-06-26 23:57 ` Wei Yang
  0 siblings, 0 replies; 51+ messages in thread
From: Wei Yang @ 2017-06-26 23:57 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Wei Yang

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

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

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

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

* linux-next: build warning after merge of the akpm tree
@ 2017-06-26  6:30 Stephen Rothwell
  2017-06-26 23:57 ` Wei Yang
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2017-06-26  6:30 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Wei Yang

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

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

* linux-next: build warning after merge of the akpm tree
@ 2013-04-18  8:03 Stephen Rothwell
  0 siblings, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2013-04-18  8:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Namjae Jeon

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

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 Rothwell                    sfr@canb.auug.org.au

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

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

* linux-next: build warning after merge of the akpm tree
@ 2013-04-10  8:33 Stephen Rothwell
  0 siblings, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2013-04-10  8:33 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel

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

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 Rothwell                    sfr@canb.auug.org.au

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

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

* linux-next: build warning after merge of the akpm tree
@ 2013-04-10  8:18 Stephen Rothwell
  0 siblings, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2013-04-10  8:18 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Philipp Zabel

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

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 Rothwell                    sfr@canb.auug.org.au

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

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

* linux-next: build warning after merge of the akpm tree
  2013-02-20  6:34 Stephen Rothwell
@ 2013-02-20 14:37 ` Peter Jones
  0 siblings, 0 replies; 51+ messages in thread
From: Peter Jones @ 2013-02-20 14:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Matt Fleming, Jens Axboe, Stephen Warren, Andrew Morton,
	linux-kernel, linux-next

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.

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

* linux-next: build warning after merge of the akpm tree
@ 2013-02-20  6:34 Stephen Rothwell
  2013-02-20 14:37 ` Peter Jones
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2013-02-20  6:34 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Peter Jones

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

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 Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2013-01-23  6:33 Stephen Rothwell
@ 2013-01-23  6:43 ` Tang Chen
  0 siblings, 0 replies; 51+ messages in thread
From: Tang Chen @ 2013-01-23  6:43 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

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 <tangchen@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

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

* linux-next: build warning after merge of the akpm tree
@ 2013-01-23  6:33 Stephen Rothwell
  2013-01-23  6:43 ` Tang Chen
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2013-01-23  6:33 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Tang Chen

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

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 Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2012-11-09  3:43 Stephen Rothwell
@ 2012-11-09 10:00 ` Grant Likely
  0 siblings, 0 replies; 51+ messages in thread
From: Grant Likely @ 2012-11-09 10:00 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Andy Shevchenko

On Fri, Nov 9, 2012 at 3:43 AM, Stephen Rothwell <sfr@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.

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

* linux-next: build warning after merge of the akpm tree
@ 2012-11-09  3:43 Stephen Rothwell
  2012-11-09 10:00 ` Grant Likely
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2012-11-09  3:43 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Andy Shevchenko, Grant Likely

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

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 Rothwell                    sfr@canb.auug.org.au

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

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

* linux-next: build warning after merge of the akpm tree
@ 2012-10-25  3:35 Stephen Rothwell
  0 siblings, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2012-10-25  3:35 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Bob Liu

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

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 Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2012-04-27  6:28   ` Stephen Rothwell
@ 2012-04-27  6:40     ` Cyrill Gorcunov
  0 siblings, 0 replies; 51+ messages in thread
From: Cyrill Gorcunov @ 2012-04-27  6:40 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Kees Cook

On Fri, Apr 27, 2012 at 04:28:58PM +1000, Stephen Rothwell wrote:
> Hi Cyrill,
> 
> > > Introduced by commit 5455a20be1a6 ("c/r: prctl: extend PR_SET_MM to set
> > > up more mm_struct entries").
> > 
> > Hi Stephen, thanks for report, have no idea how it happened, since
> > commit 5455a20be1a6 _has_ error = -EINVAL; line.
> 
> I blamed the wrong patch :-(
> 
> Commit 8f62e9e9ed ("c/r: prctl: simplify PR_SET_MM on mm::code/data
> assignment") removes the "error = -EINVAL".

Ah, could be. Please merge up the fix then (there were another patches
in Andrew's queue where this nit is fixed I think, but they are not yet
in -next). So this fix should do the trick. Thanks.

	Cyrill

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

* Re: linux-next: build warning after merge of the akpm tree
  2012-04-27  6:22 ` Cyrill Gorcunov
@ 2012-04-27  6:28   ` Stephen Rothwell
  2012-04-27  6:40     ` Cyrill Gorcunov
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2012-04-27  6:28 UTC (permalink / raw)
  To: Cyrill Gorcunov; +Cc: Andrew Morton, linux-next, linux-kernel, Kees Cook

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

Hi Cyrill,

On Fri, 27 Apr 2012 10:22:18 +0400 Cyrill Gorcunov <gorcunov@openvz.org> wrote:
>
> On Fri, Apr 27, 2012 at 03:44:20PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the akpm tree, today's linux-next build ()
> > produced this warning:
> > 
> > kernel/sys.c: In function 'prctl_set_mm':
> > kernel/sys.c:1779:6: warning: 'error' may be used uninitialized in this function [-Wuninitialized]
> > 
> > And this is not a false positive (I think).
> > 
> > Introduced by commit 5455a20be1a6 ("c/r: prctl: extend PR_SET_MM to set
> > up more mm_struct entries").
> 
> Hi Stephen, thanks for report, have no idea how it happened, since
> commit 5455a20be1a6 _has_ error = -EINVAL; line.

I blamed the wrong patch :-(

Commit 8f62e9e9ed ("c/r: prctl: simplify PR_SET_MM on mm::code/data
assignment") removes the "error = -EINVAL".

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

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

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

* Re: linux-next: build warning after merge of the akpm tree
  2012-04-27  5:44 Stephen Rothwell
@ 2012-04-27  6:22 ` Cyrill Gorcunov
  2012-04-27  6:28   ` Stephen Rothwell
  0 siblings, 1 reply; 51+ messages in thread
From: Cyrill Gorcunov @ 2012-04-27  6:22 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Kees Cook

On Fri, Apr 27, 2012 at 03:44:20PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build ()
> produced this warning:
> 
> kernel/sys.c: In function 'prctl_set_mm':
> kernel/sys.c:1779:6: warning: 'error' may be used uninitialized in this function [-Wuninitialized]
> 
> And this is not a false positive (I think).
> 
> Introduced by commit 5455a20be1a6 ("c/r: prctl: extend PR_SET_MM to set
> up more mm_struct entries").

Hi Stephen, thanks for report, have no idea how it happened, since
commit 5455a20be1a6 _has_ error = -EINVAL; line.
Anyway, here is a fix.

	Cyrill
---
From: Cyrill Gorcunov <gorcunov@openvz.org>
Subject: [PATCH -mm] c/r: prctl: Add error initialization

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Kees Cook <keescook@chromium.org>
---
 kernel/sys.c |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6.git/kernel/sys.c
===================================================================
--- linux-2.6.git.orig/kernel/sys.c
+++ linux-2.6.git/kernel/sys.c
@@ -1790,6 +1790,8 @@ static int prctl_set_mm(int opt, unsigne
 	if (addr >= TASK_SIZE)
 		return -EINVAL;
 
+	error = -EINVAL;
+
 	down_read(&mm->mmap_sem);
 	vma = find_vma(mm, addr);
 

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

* linux-next: build warning after merge of the akpm tree
@ 2012-04-27  5:44 Stephen Rothwell
  2012-04-27  6:22 ` Cyrill Gorcunov
  0 siblings, 1 reply; 51+ messages in thread
From: Stephen Rothwell @ 2012-04-27  5:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Cyrill Gorcunov, Kees Cook

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

Hi Andrew,

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

kernel/sys.c: In function 'prctl_set_mm':
kernel/sys.c:1779:6: warning: 'error' may be used uninitialized in this function [-Wuninitialized]

And this is not a false positive (I think).

Introduced by commit 5455a20be1a6 ("c/r: prctl: extend PR_SET_MM to set
up more mm_struct entries").

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

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

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

* linux-next: build warning after merge of the akpm tree
@ 2011-08-10  2:13 Stephen Rothwell
  0 siblings, 0 replies; 51+ messages in thread
From: Stephen Rothwell @ 2011-08-10  2:13 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Will Drewry

Hi Andrew,

After merging the akpm tree, today's linux-next build (lost of them)
produced this warning:

WARNING: init/mounts.o(.text+0x192): Section mismatch in reference from the function devt_from_partuuid() to the variable .init.data:root_wait
The function devt_from_partuuid() references
the variable __initdata root_wait.
This is often because devt_from_partuuid lacks a __initdata 
annotation or the annotation of root_wait is wrong.

Commit 185237e4cfab ("This patch makes two changes:"
init-add-root=partuuid=uuid-partnroff=%d-support-update.patch) adds the
reference to root_wait from the non-init function devt_from_partuuid().

The easiest thing to do is to remove __init_date from root_wait.

I have applied this patch as a merge fixup for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Aug 2011 12:09:35 +1000
Subject: [PATCH] do_mounts: remove __init_data from root_wait

as it is now used from a non init routine.

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

diff --git a/init/do_mounts.c b/init/do_mounts.c
index bcbeca7..0f6e1d9 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -28,7 +28,7 @@ int __initdata rd_doload;	/* 1 = load RAM disk, 0 = don't load */
 int root_mountflags = MS_RDONLY | MS_SILENT;
 static char * __initdata root_device_name;
 static char __initdata saved_root_name[64];
-static int __initdata root_wait;
+static int root_wait;
 
 dev_t ROOT_DEV;
 
-- 
1.7.5.4

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

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

end of thread, other threads:[~2021-02-01  7:27 UTC | newest]

Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-19  8:13 linux-next: build warning after merge of the akpm tree Stephen Rothwell
2014-05-19 15:13 ` Davidlohr Bueso
2014-05-19 19:48   ` Andrew Morton
2014-05-19 20:56     ` Davidlohr Bueso
2014-05-19 21:17       ` Andrew Morton
2014-05-19 21:36   ` Stephen Rothwell
2014-05-19 22:38     ` Davidlohr Bueso
  -- strict thread matches above, loose matches on Subject: below --
2021-01-28  8:46 Stephen Rothwell
2021-02-01  7:14 ` Vijayanand Jitta
2020-12-04 10:00 Stephen Rothwell
2020-12-05  5:19 ` Andrew Morton
2020-12-05  9:37   ` Stephen Rothwell
2020-12-07 12:08   ` Dmitry Vyukov
2020-12-07 12:38     ` Dmitry Vyukov
2020-12-07 12:52       ` Marco Elver
2020-12-09 10:06         ` Dmitry Vyukov
2020-12-08 12:01 ` Stephen Rothwell
2020-12-09  4:44   ` Michael Ellerman
2020-12-09  7:07     ` Stephen Rothwell
2020-12-10  0:19       ` Michael Ellerman
2020-12-10 21:17         ` Stephen Rothwell
2020-12-09 10:33   ` Stephen Rothwell
2020-12-09 18:56   ` Kees Cook
2020-02-28  4:35 Stephen Rothwell
2020-02-28  5:23 ` Arjun Roy
2020-01-06  6:11 Stephen Rothwell
2020-01-06  6:07 Stephen Rothwell
2020-01-07 23:11 ` Andrew Morton
2020-01-08 14:52   ` Steven Price
2018-11-30  5:40 Stephen Rothwell
2018-11-30 14:52 ` Dave Rodgman
2017-08-01  6:02 Stephen Rothwell
2017-08-01  6:15 ` Huang, Ying
2017-08-01 21:15   ` Arnd Bergmann
2017-06-26  6:30 Stephen Rothwell
2017-06-26 23:57 ` Wei Yang
2013-04-18  8:03 Stephen Rothwell
2013-04-10  8:33 Stephen Rothwell
2013-04-10  8:18 Stephen Rothwell
2013-02-20  6:34 Stephen Rothwell
2013-02-20 14:37 ` Peter Jones
2013-01-23  6:33 Stephen Rothwell
2013-01-23  6:43 ` Tang Chen
2012-11-09  3:43 Stephen Rothwell
2012-11-09 10:00 ` Grant Likely
2012-10-25  3:35 Stephen Rothwell
2012-04-27  5:44 Stephen Rothwell
2012-04-27  6:22 ` Cyrill Gorcunov
2012-04-27  6:28   ` Stephen Rothwell
2012-04-27  6:40     ` Cyrill Gorcunov
2011-08-10  2:13 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).