diff mbox

kbuild: modpost: Warn about references from rodata to __init text

Message ID 20170630225822.25349-1-sboyd@codeaurora.org (mailing list archive)
State Deferred
Delegated to: Andy Gross
Headers show

Commit Message

Stephen Boyd June 30, 2017, 10:58 p.m. UTC
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 <robdclark@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---

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(-)

Comments

Rob Clark June 30, 2017, 11:59 p.m. UTC | #1
On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd <sboyd@codeaurora.org> 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 <robdclark@gmail.com>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
kernel test robot July 2, 2017, 1:35 a.m. UTC | #2
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
Masahiro Yamada July 18, 2017, 6:38 p.m. UTC | #3
2017-07-01 7:58 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:
> 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 <robdclark@gmail.com>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> 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.  :-)
Masahiro Yamada July 20, 2017, 2:28 p.m. UTC | #4
Hi Stephen, Rob,

2017-07-01 8:59 GMT+09:00 Rob Clark <robdclark@gmail.com>:
> On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd <sboyd@codeaurora.org> 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 <robdclark@gmail.com>
>> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Boyd July 20, 2017, 5:52 p.m. UTC | #5
On 07/20, Masahiro Yamada wrote:
> Hi Stephen, Rob,
> 
> 2017-07-01 8:59 GMT+09:00 Rob Clark <robdclark@gmail.com>:
> > On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd <sboyd@codeaurora.org> 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 <robdclark@gmail.com>
> >> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> >> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >> ---
> >>
> >> 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.
Masahiro Yamada July 21, 2017, 3:57 p.m. UTC | #6
Hi Stephen,


2017-07-21 2:52 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:
> On 07/20, Masahiro Yamada wrote:
>> Hi Stephen, Rob,
>>
>> 2017-07-01 8:59 GMT+09:00 Rob Clark <robdclark@gmail.com>:
>> > On Fri, Jun 30, 2017 at 6:58 PM, Stephen Boyd <sboyd@codeaurora.org> 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 <robdclark@gmail.com>
>> >> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
>> >> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> >> ---
>> >>
>> >> 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.
diff mbox

Patch

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", \