devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
	Rob Herring <robh+dt@kernel.org>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	Pantelis Antoniou <panto@antoniou-consulting.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Subject: Re: [PATCH v5 1/4] of: change overlay apply input data from unflattened to FDT
Date: Fri, 2 Mar 2018 09:28:22 -0800	[thread overview]
Message-ID: <fdfb7ab1-d74c-4398-b86d-cbf4de8d80bf@gmail.com> (raw)
In-Reply-To: <CAMuHMdWCjqugdSkpLczcD3xsNWMmsZC8z0RLF7iQfL3V95LMZQ@mail.gmail.com>

On 03/02/18 01:20, Geert Uytterhoeven wrote:
> Hi Frank,
> 
> On Fri, Mar 2, 2018 at 2:51 AM,  <frowand.list@gmail.com> wrote:
>> There are still some functions in unittest.c that should be tagged
>> __init due to changes in this patch, but modpost is not warning of
>> them and they are not a risk because they are only called from
>> __init functions.  A sweep of unittest.c for functions that
>> should be tagged __init is on the todo list.
> 
> If modpost doesn't warn, that merely means your compiler decided to
> inline all functions with wrong annotations, hiding the problem.
> Other (versions of) compilers may behave differently, so we do want
> to get this right.
> 
> With my trusty gcc-4.1.2:
> 
>     WARNING: vmlinux.o(.text+0x342dd4): Section mismatch in reference
> from the function of_unittest_apply_revert_overlay_check() to the
> function .init.text:of_unittest_apply_overlay()
>     The function of_unittest_apply_revert_overlay_check() references
>     the function __init of_unittest_apply_overlay().
>     This is often because of_unittest_apply_revert_overlay_check lacks a __init
>     annotation or the annotation of of_unittest_apply_overlay is wrong.
> 
> To fix the above:
> 
> -static int of_unittest_apply_revert_overlay_check(int overlay_nr,
> +static int __init of_unittest_apply_revert_overlay_check(int overlay_nr,
> -static void of_unittest_overlay_5(void)
> +static void __init of_unittest_overlay_5(void)
> -static void of_unittest_overlay_11(void)
> +static void __init of_unittest_overlay_11(void)

Yes, that is exactly the extra set of functions I was talking about.  Even
though I would prefer to annotate them, in practice they will not be a
problem because they only get called from __init functions (either directly
or indirectly).  But if Rob will take a patch with them annotated, I will
spin the series.


>> --- a/drivers/of/unittest.c
>> +++ b/drivers/of/unittest.c
> 
>> @@ -2290,18 +2275,29 @@ static __init void of_unittest_overlay_high_level(void)
>>                 __of_attach_node_sysfs(np);
>>
>>         if (of_symbols) {
>> +               struct property *new_prop;
>>                 for_each_property_of_node(overlay_base_symbols, prop) {
> 
> drivers/of/unittest.c: In function ‘of_unittest_overlay_high_level’:
> drivers/of/unittest.c:2193: warning: ‘overlay_base_symbols’ may be
> used uninitialized in this function
> 
> This isn't a new warning, so I guess I never reported it before because I
> thought it was a false positive (misguided by the "if (of_symbols)" test?).
> 
> However, now I believe it is not, and an uninitialized pointer will be
> dereferenced if of_root has a __symbols__ node, but overlay_base_root hasn't.

Yes, thanks for reporting it.  My gcc isn't this smart.

Fortunately overlay_base_root does have a __symbols__ node.  But I will fix it
in a patch outside this series.


> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

  reply	other threads:[~2018-03-02 17:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02  1:51 [PATCH v5 0/4] of: change overlay apply input data from unflattened frowand.list
2018-03-02  1:51 ` [PATCH v5 1/4] of: change overlay apply input data from unflattened to FDT frowand.list
2018-03-02  9:20   ` Geert Uytterhoeven
2018-03-02 17:28     ` Frank Rowand [this message]
2018-03-02  1:51 ` [PATCH v5 2/4] of: Documentation: of_overlay_apply() replaced by of_overlay_fdt_apply() frowand.list
2018-03-02  1:51 ` [PATCH v5 3/4] of: convert unittest overlay devicetree source to sugar syntax frowand.list
2018-03-02  1:52 ` [PATCH v5 4/4] of: improve reporting invalid overlay target path frowand.list
2018-03-02 13:36 ` [PATCH v5 0/4] of: change overlay apply input data from unflattened Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fdfb7ab1-d74c-4398-b86d-cbf4de8d80bf@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=panto@antoniou-consulting.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).