linux-kernel - Re: [PATCH] of: introduce event tracepoints for dynamic device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <58F90D56.9070602@gmail.com>
Date:   Thu, 20 Apr 2017 12:34:46 -0700
From:   Frank Rowand <frowand.list@...il.com>
To:     Tyrel Datwyler <turtle.in.the.kernel@...il.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Tyrel Datwyler <tyreld@...ux.vnet.ibm.com>, robh+dt@...nel.org
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, nfont@...ux.vnet.ibm.com,
        rostedt@...dmis.org, mingo@...hat.com
Subject: Re: [PATCH] of: introduce event tracepoints for dynamic device_node
 lifecyle

On 04/20/17 09:51, Tyrel Datwyler wrote:
> On 04/19/2017 09:43 PM, Frank Rowand wrote:
> 

< snip >


>> The call stack could easily be post-processed, for example using addr2line.
>> Here is the call stack for when the refcount incremented to 23 from 22 (or
>> more accurately, to 22 from 21):
>>
>> 0xc0d00e3c Line 857 of "init/main.c"
>> 0xc03017d0 Line 792 of "init/main.c"
>> 0xc0d3a234 Line 528 of "drivers/of/platform.c"
>> 0xc0810684 Line 503 of "drivers/of/platform.c"
>> 0xc081061c Line 267 of "include/linux/of.h"
>> 0xc080d928 Line 815 of "drivers/of/base.c"
>>
>> Which ends up being this code:
>>
>>    of_platform_default_populate_init()
>>       of_platform_default_populate()
>>          of_platform_populate()
>>             [[ of_find_node_by_path("/") ]]
>>                [[ of_find_node_opts_by_path(path, NULL) ]]
>>                   of_node_get(of_root)
>>
>> Note that some functions can be left out of the ARM call stack, with
>> a return going back more than one level.  The functions in the call
>> list above that are enclosed in '[[' and ']]' were found by source
>> inspection in those cases.
> 
> The same thing is encountered in ppc64 stack traces. I assume it is
> generally inlining of small functions, but I've never actually verified
> that theory. Probably should take the time to investigate, or just ask
> someone.

Yes, inlining small functions is one reason for this.

Another case I often find is that when function A calls function B calls
function C.  If the final statement of function B is 'return C()' then
there is no need for function C to return through function B, it can
instead return directly to function A.  (That is more a conceptual
hand-waving of the idea, not the actual way the compiler implements
it.  Take this with a grain of salt, I'm not a compiler guy.)

< snip >