Moving __write_once_size out of line causes a section mismatch warning
with clang in one instance:
WARNING: modpost: vmlinux.o(.text+0x8dc): Section mismatch in reference from the function __write_once_size() to the variable .init.data:blacklisted_initcalls
The function __write_once_size() references
the variable __initdata blacklisted_initcalls.
This is often because __write_once_size lacks a __initdata
annotation or the annotation of blacklisted_initcalls is wrong.
Remove the __init_or_module annotation from the variable as a workaround.
Fixes: dfd402a4c4ba ("kcsan: Add Kernel Concurrency Sanitizer infrastructure")
Signed-off-by: Arnd Bergmann <[email protected]>
---
So far, my randconfig checks found two such instances, one for read_once
and one for write_once. There are probably a couple more in random
configurations, but I guess they are rare enough that we can just work
around them like this.
---
init/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/main.c b/init/main.c
index 8f78399697e3..441c384a73cd 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1020,7 +1020,7 @@ struct blacklist_entry {
char *buf;
};
-static __initdata_or_module LIST_HEAD(blacklisted_initcalls);
+static LIST_HEAD(blacklisted_initcalls);
static int __init initcall_blacklist(char *str)
{
--
2.26.0
On Tue, 5 May 2020 at 16:11, Arnd Bergmann <[email protected]> wrote:
>
> Moving __write_once_size out of line causes a section mismatch warning
> with clang in one instance:
>
> WARNING: modpost: vmlinux.o(.text+0x8dc): Section mismatch in reference from the function __write_once_size() to the variable .init.data:blacklisted_initcalls
> The function __write_once_size() references
> the variable __initdata blacklisted_initcalls.
> This is often because __write_once_size lacks a __initdata
> annotation or the annotation of blacklisted_initcalls is wrong.
>
> Remove the __init_or_module annotation from the variable as a workaround.
>
> Fixes: dfd402a4c4ba ("kcsan: Add Kernel Concurrency Sanitizer infrastructure")
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> So far, my randconfig checks found two such instances, one for read_once
> and one for write_once. There are probably a couple more in random
> configurations, but I guess they are rare enough that we can just work
> around them like this.
[+Cc Will]
Thanks for testing and fixing this. Note that this may no longer be
necessary once Will's patches land. Also noted here:
https://lkml.kernel.org/r/CANpmjNNw6M9Gqj6WGTHH4Cegu8roTVu5x6Vqs_tCBxX3gPwL4A@mail.gmail.com
For reference, Will's series:
https://lore.kernel.org/lkml/[email protected]/
Thanks,
-- Marco
> ---
> init/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/init/main.c b/init/main.c
> index 8f78399697e3..441c384a73cd 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1020,7 +1020,7 @@ struct blacklist_entry {
> char *buf;
> };
>
> -static __initdata_or_module LIST_HEAD(blacklisted_initcalls);
> +static LIST_HEAD(blacklisted_initcalls);
>
> static int __init initcall_blacklist(char *str)
> {
> --
> 2.26.0
>
On Tue, May 5, 2020 at 4:17 PM 'Marco Elver' via Clang Built Linux
<[email protected]> wrote:
> On Tue, 5 May 2020 at 16:11, Arnd Bergmann <[email protected]> wrote:
> > So far, my randconfig checks found two such instances, one for read_once
> > and one for write_once. There are probably a couple more in random
> > configurations, but I guess they are rare enough that we can just work
> > around them like this.
>
> [+Cc Will]
>
> Thanks for testing and fixing this. Note that this may no longer be
> necessary once Will's patches land. Also noted here:
> https://lkml.kernel.org/r/CANpmjNNw6M9Gqj6WGTHH4Cegu8roTVu5x6Vqs_tCBxX3gPwL4A@mail.gmail.com
>
> For reference, Will's series:
> https://lore.kernel.org/lkml/[email protected]/
Right, good point. If that is going to get merged for the same release, we don't
need my workarounds and I'll just keep them applied locally in my linux-next
randconfig tree for the moment.
Arnd
On Tue, May 05, 2020 at 05:05:36PM +0200, Arnd Bergmann wrote:
> On Tue, May 5, 2020 at 4:17 PM 'Marco Elver' via Clang Built Linux
> <[email protected]> wrote:
> > On Tue, 5 May 2020 at 16:11, Arnd Bergmann <[email protected]> wrote:
> > > So far, my randconfig checks found two such instances, one for read_once
> > > and one for write_once. There are probably a couple more in random
> > > configurations, but I guess they are rare enough that we can just work
> > > around them like this.
> >
> > [+Cc Will]
> >
> > Thanks for testing and fixing this. Note that this may no longer be
> > necessary once Will's patches land. Also noted here:
> > https://lkml.kernel.org/r/CANpmjNNw6M9Gqj6WGTHH4Cegu8roTVu5x6Vqs_tCBxX3gPwL4A@mail.gmail.com
> >
> > For reference, Will's series:
> > https://lore.kernel.org/lkml/[email protected]/
>
> Right, good point. If that is going to get merged for the same release, we don't
> need my workarounds and I'll just keep them applied locally in my linux-next
> randconfig tree for the moment.
I'll send out a new version based on the kcsan stuff this week, so fingers
crossed for 5.8!
Will