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  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]
Date:   Sun, 8 Oct 2017 11:56:14 -0700
From:   Joel Fernandes <>
To:     Steven Rostedt <>
Cc:     Linux Kernel Mailing List <>,
        Ingo Molnar <>,
        Andrew Morton <>,
        Jessica Yu <>,
        "Joel Fernandes (Google)" <>
Subject: Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod_maps

Hi Steve,

On Sun, Oct 8, 2017 at 11:42 AM, Steven Rostedt <> wrote:
> On Sun, 8 Oct 2017 01:42:15 -0700
>> > "Joel Fernandes (Google)" <> wrote:
>> [..]
>> > Also could you let me know what is the correct behavior of the filters
>> > after a module being traced is unloaded, are the filters supposed to
>> > be setup again after the module is unloaded, before the module can be
>> > loaded again?
>> Actually I learnt that it doesn't get preserved and wrote a patch to fix that, let me know
>> what you think, thanks. (its only lightly tested - checked that the filters are preserved,
>> will do more testing tomorrow):
> They should not be preserved, it's too non-deterministic.

Could you elaborate more on non-deterministic?

Say a user setup filters with '*:mod:<mod-name>' and unloads and
loads, then the filter carrying forward for the second load helps
avoid having them to set it up again.

OTOH I agree its not a big deal to set up the filters again, and
probably not worth save it if it complicates the code too much to
handle all cases.

> I'm wondering why the setting of the ip to zero didn't keep it from
> showing up again. I'll have to investigate that.

Ok. Happy to help test anything you want to try :) I *think* the 'bar'
function that showed up the second time around is actually the address
of the init function in the previous load, and probably the new code
you added switched it on but I have yet to debug it (you'll probably
beat me to it since you wrote this code ;)).


- Joel

Powered by blists - more mailing lists