If we have a structure that's marked const it will be placed
into the .rodata section but it could reference an init section
function. Include the read only data section in the check we have
for read/write data sections referencing init sections so we can
find this class of problems. This exposes quite a few places
where const marked structures are referencing __init functions and
__init data that we were previously ignoring.
Cc: Rob Clark <[email protected]>
Cc: Bjorn Andersson <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
---
Making this change leads to quite a few other errors even on the
multi_v7_defconfig for ARM[1]. I still need to do a build of the
allmodconfig to see how many other errors there, but it seems to
be quite a few. I suppose those will need to be fixed before we can
merge this?
[1] https://www.irccloud.com/pastebin/zzqfWGQY/
scripts/mod/modpost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 48397feb08fb..4f2be5c6727d 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -903,7 +903,7 @@ static void check_section(const char *modname, struct elf_info *elf,
#define ALL_INIT_SECTIONS INIT_SECTIONS, ALL_XXXINIT_SECTIONS
#define ALL_EXIT_SECTIONS EXIT_SECTIONS, ALL_XXXEXIT_SECTIONS
-#define DATA_SECTIONS ".data", ".data.rel"
+#define DATA_SECTIONS ".rodata", ".data", ".data.rel"
#define TEXT_SECTIONS ".text", ".text.unlikely", ".sched.text", \
".kprobes.text", ".cpuidle.text"
#define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd <[email protected]> wrote:
> If we have a structure that's marked const it will be placed
> into the .rodata section but it could reference an init section
> function. Include the read only data section in the check we have
> for read/write data sections referencing init sections so we can
> find this class of problems. This exposes quite a few places
> where const marked structures are referencing __init functions and
> __init data that we were previously ignoring.
>
> Cc: Rob Clark <[email protected]>
> Cc: Bjorn Andersson <[email protected]>
> Signed-off-by: Stephen Boyd <[email protected]>
> ---
>
> Making this change leads to quite a few other errors even on the
> multi_v7_defconfig for ARM[1]. I still need to do a build of the
> allmodconfig to see how many other errors there, but it seems to
> be quite a few. I suppose those will need to be fixed before we can
> merge this?
thanks.. the explosions you get with these mistakes when building
drivers as modules in a distro kernel config are quite "fun" to
debug..
I'm not quite sure about the rules for whether merging this would
count as a regression, but I would argue those drivers are already
broken, just no one noticed yet. Similar to when a new gcc gets more
clever about detecting bugs. So I wouldn't be against merging this
first to force drivers to fix their crap ;-)
BR,
-R
> [1] https://www.irccloud.com/pastebin/zzqfWGQY/
>
> scripts/mod/modpost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 48397feb08fb..4f2be5c6727d 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -903,7 +903,7 @@ static void check_section(const char *modname, struct elf_info *elf,
> #define ALL_INIT_SECTIONS INIT_SECTIONS, ALL_XXXINIT_SECTIONS
> #define ALL_EXIT_SECTIONS EXIT_SECTIONS, ALL_XXXEXIT_SECTIONS
>
> -#define DATA_SECTIONS ".data", ".data.rel"
> +#define DATA_SECTIONS ".rodata", ".data", ".data.rel"
> #define TEXT_SECTIONS ".text", ".text.unlikely", ".sched.text", \
> ".kprobes.text", ".cpuidle.text"
> #define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Hi Stephen,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.12-rc7 next-20170630]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Stephen-Boyd/kbuild-modpost-Warn-about-references-from-rodata-to-__init-text/20170702-074024
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All warnings (new ones prefixed by >>):
>> WARNING: drivers/ata/libata.o(.rodata+0xbb4): Section mismatch in reference from the variable ___param_string_force to the variable .init.data:_ata_force_param_buf
The variable ___param_string_force references
the variable __initdata _ata_force_param_buf
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
>> WARNING: net/built-in.o(.rodata+0x5d08): Section mismatch in reference from the variable _msstab to the (unknown reference) .init.text:(unknown)
The variable _msstab references
the (unknown reference) __init (unknown)
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
>> WARNING: drivers/tty/built-in.o(.rodata+0x1790): Section mismatch in reference from the variable _uart_proc_fops to the (unknown reference) .init.text:(unknown)
The variable _uart_proc_fops references
the (unknown reference) __init (unknown)
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
>> WARNING: drivers/thermal/qcom/qcom_tsens.o(.rodata+0x434): Section mismatch in reference from the variable _ops_8916 to the function .init.text:_init_common()
The variable _ops_8916 references
the function __init _init_common()
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
>> WARNING: drivers/thermal/qcom/qcom_tsens.o(.rodata+0x460): Section mismatch in reference from the variable _ops_8974 to the function .init.text:_init_common()
The variable _ops_8974 references
the function __init _init_common()
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
>> WARNING: drivers/thermal/qcom/qcom_tsens.o(.rodata+0x4b8): Section mismatch in reference from the variable _ops_8996 to the function .init.text:_init_common()
The variable _ops_8996 references
the function __init _init_common()
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
>> WARNING: drivers/of/built-in.o(.rodata+0x714): Section mismatch in reference from the variable _CSWTCH.7 to the (unknown reference) .init.text:(unknown)
The variable _CSWTCH.7 references
the (unknown reference) __init (unknown)
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
>> WARNING: kernel/built-in.o(.rodata+0x28d8): Section mismatch in reference from the variable _param.25627 to the (unknown reference) .init.text:(unknown)
The variable _param.25627 references
the (unknown reference) __init (unknown)
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
2017-07-01 7:58 GMT+09:00 Stephen Boyd <[email protected]>:
> If we have a structure that's marked const it will be placed
> into the .rodata section but it could reference an init section
> function. Include the read only data section in the check we have
> for read/write data sections referencing init sections so we can
> find this class of problems. This exposes quite a few places
> where const marked structures are referencing __init functions and
> __init data that we were previously ignoring.
>
> Cc: Rob Clark <[email protected]>
> Cc: Bjorn Andersson <[email protected]>
> Signed-off-by: Stephen Boyd <[email protected]>
> ---
>
> Making this change leads to quite a few other errors even on the
> multi_v7_defconfig for ARM[1]. I still need to do a build of the
> allmodconfig to see how many other errors there, but it seems to
> be quite a few. I suppose those will need to be fixed before we can
> merge this?
>
> [1] https://www.irccloud.com/pastebin/zzqfWGQY/
Applied to linux-kbuild/misc. Thanks!
Now people will notice the warnings in linux-next,
and will start fixing drivers.
We still have plenty of time until the next merge windows. :-)
--
Best Regards
Masahiro Yamada
Hi Stephen, Rob,
2017-07-01 8:59 GMT+09:00 Rob Clark <[email protected]>:
> On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd <[email protected]> wrote:
>> If we have a structure that's marked const it will be placed
>> into the .rodata section but it could reference an init section
>> function. Include the read only data section in the check we have
>> for read/write data sections referencing init sections so we can
>> find this class of problems. This exposes quite a few places
>> where const marked structures are referencing __init functions and
>> __init data that we were previously ignoring.
>>
>> Cc: Rob Clark <[email protected]>
>> Cc: Bjorn Andersson <[email protected]>
>> Signed-off-by: Stephen Boyd <[email protected]>
>> ---
>>
>> Making this change leads to quite a few other errors even on the
>> multi_v7_defconfig for ARM[1]. I still need to do a build of the
>> allmodconfig to see how many other errors there, but it seems to
>> be quite a few. I suppose those will need to be fixed before we can
>> merge this?
>
> thanks.. the explosions you get with these mistakes when building
> drivers as modules in a distro kernel config are quite "fun" to
> debug..
>
> I'm not quite sure about the rules for whether merging this would
> count as a regression, but I would argue those drivers are already
> broken, just no one noticed yet. Similar to when a new gcc gets more
> clever about detecting bugs. So I wouldn't be against merging this
> first to force drivers to fix their crap ;-)
I applied this, but this way seems unacceptable.
I cannot send a pull-req for this
unless most of the warnings are fixed.
Is there any activity for driver fixes?
On 07/20, Masahiro Yamada wrote:
> Hi Stephen, Rob,
>
> 2017-07-01 8:59 GMT+09:00 Rob Clark <[email protected]>:
> > On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd <[email protected]> wrote:
> >> If we have a structure that's marked const it will be placed
> >> into the .rodata section but it could reference an init section
> >> function. Include the read only data section in the check we have
> >> for read/write data sections referencing init sections so we can
> >> find this class of problems. This exposes quite a few places
> >> where const marked structures are referencing __init functions and
> >> __init data that we were previously ignoring.
> >>
> >> Cc: Rob Clark <[email protected]>
> >> Cc: Bjorn Andersson <[email protected]>
> >> Signed-off-by: Stephen Boyd <[email protected]>
> >> ---
> >>
> >> Making this change leads to quite a few other errors even on the
> >> multi_v7_defconfig for ARM[1]. I still need to do a build of the
> >> allmodconfig to see how many other errors there, but it seems to
> >> be quite a few. I suppose those will need to be fixed before we can
> >> merge this?
> >
> > thanks.. the explosions you get with these mistakes when building
> > drivers as modules in a distro kernel config are quite "fun" to
> > debug..
> >
> > I'm not quite sure about the rules for whether merging this would
> > count as a regression, but I would argue those drivers are already
> > broken, just no one noticed yet. Similar to when a new gcc gets more
> > clever about detecting bugs. So I wouldn't be against merging this
> > first to force drivers to fix their crap ;-)
>
> I applied this, but this way seems unacceptable.
> I cannot send a pull-req for this
> unless most of the warnings are fixed.
>
> Is there any activity for driver fixes?
Sorry, no. I've only had a little time to look at the errors
reported. Some of them seem to be noise, because there are
structures that have a handful of members where one of the
members points to an __init function or piece of data that is
only used in __init code. We would need to mark these structures
as __ref or write more complicated section mismatch checking code
to be silent in these cases.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi Stephen,
2017-07-21 2:52 GMT+09:00 Stephen Boyd <[email protected]>:
> On 07/20, Masahiro Yamada wrote:
>> Hi Stephen, Rob,
>>
>> 2017-07-01 8:59 GMT+09:00 Rob Clark <[email protected]>:
>> > On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd <[email protected]> wrote:
>> >> If we have a structure that's marked const it will be placed
>> >> into the .rodata section but it could reference an init section
>> >> function. Include the read only data section in the check we have
>> >> for read/write data sections referencing init sections so we can
>> >> find this class of problems. This exposes quite a few places
>> >> where const marked structures are referencing __init functions and
>> >> __init data that we were previously ignoring.
>> >>
>> >> Cc: Rob Clark <[email protected]>
>> >> Cc: Bjorn Andersson <[email protected]>
>> >> Signed-off-by: Stephen Boyd <[email protected]>
>> >> ---
>> >>
>> >> Making this change leads to quite a few other errors even on the
>> >> multi_v7_defconfig for ARM[1]. I still need to do a build of the
>> >> allmodconfig to see how many other errors there, but it seems to
>> >> be quite a few. I suppose those will need to be fixed before we can
>> >> merge this?
>> >
>> > thanks.. the explosions you get with these mistakes when building
>> > drivers as modules in a distro kernel config are quite "fun" to
>> > debug..
>> >
>> > I'm not quite sure about the rules for whether merging this would
>> > count as a regression, but I would argue those drivers are already
>> > broken, just no one noticed yet. Similar to when a new gcc gets more
>> > clever about detecting bugs. So I wouldn't be against merging this
>> > first to force drivers to fix their crap ;-)
>>
>> I applied this, but this way seems unacceptable.
>> I cannot send a pull-req for this
>> unless most of the warnings are fixed.
>>
>> Is there any activity for driver fixes?
>
> Sorry, no. I've only had a little time to look at the errors
> reported. Some of them seem to be noise, because there are
> structures that have a handful of members where one of the
> members points to an __init function or piece of data that is
> only used in __init code. We would need to mark these structures
> as __ref or write more complicated section mismatch checking code
> to be silent in these cases.
OK. I will drop this patch for now.
--
Best Regards
Masahiro Yamada