linux-kernel - Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAJWu+oq6VBp=jGdj6X_VHb74aKV4yFeQn=mkpzX0hYNyBpUPCQ@mail.gmail.com>
Date:   Sun, 8 Oct 2017 23:02:06 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     "Joel Fernandes (Google)" <joel.opensrc@...il.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jessica Yu <jeyu@...nel.org>
Subject: Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod_maps

Hi Steve,

On Sat, Oct 7, 2017 at 9:52 PM, Joel Fernandes (Google)
<joel.opensrc@...il.com> wrote:
[..]
>>>
>>> On Fri, Oct 6, 2017 at 11:07 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>>> > From: "Steven Rostedt (VMware)" <rostedt@...dmis.org>
>>> >
>>> > The ftrace_mod_map is a descriptor to save module init function names in
>>> > case they were traced, and the trace output needs to reference the function
>>> > name from the function address. But after the function is unloaded, it
>>> > the maps should be freed, as the rest of the function names are as well.
>>>
>>> Just checking for my understanding of this patch - wouldn't this also
>>> mean that if there were any look ups of the init functions that may be
>>> needed at trace output time, then those look ups wont be possible any
>>> more after module is unloaded?
>>
>> Yes. That's true for all functions in the module. When a module is
>> unloaded, all references to it in kallsyms is also freed. Try it on a
>> current kernel. Trace a function in a module, then unload that module.
>> The trace data will just show the ip hex address of the module function
>> after that.
>>
>
> I tried your core branch and I see some weirdness with the filters:
>
> Here's the code for the module:
> ================================================
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
>
> void bar(void)
> {
>     printk(KERN_INFO "bar!\n");
> }
>
> void foo(void)
> {
>     printk(KERN_INFO "foo!\n");
>     bar();
> }
>
> static int __init hello_init(void)
> {
>     printk(KERN_INFO "Hello world!\n");
>     foo();
>     return 0;
> }
>
> static void __exit hello_cleanup(void)
> {
>     printk(KERN_INFO "Cleaning up module.\n");
> }
>
> module_init(hello_init);
> module_exit(hello_cleanup);
> ================================================
[..]
> Also I wasn't able to see the call from hello_init -> bar and bar ->
> foo so I'm not fully sure if that's a bug or I did something wrong.
> I'm happy to try out anything you suggest.

This was I think because of function inlining, using 'noinline' on the
foo and bar functions in the above module makes it all work properly
(tested on ftrace/core branch).

thanks,

- Joel