Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1692985 > unrolled thread

Re: [PATCH] kbuild: modpost: Warn about references from rodata to __init text

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] kbuild: modpost: Warn about references from rodata to  __init text Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-07-20 16:30 +0200
    Re: [PATCH] kbuild: modpost: Warn about references from rodata to  __init text Stephen Boyd <sboyd@codeaurora.org> - 2017-07-20 20:00 +0200
      Re: [PATCH] kbuild: modpost: Warn about references from rodata to  __init text Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-07-21 18:00 +0200

#1692985 — Re: [PATCH] kbuild: modpost: Warn about references from rodata to __init text

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?

[toc] | [next] | [standalone]

#1693146

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.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1693818

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.



-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web