Messages in this thread | | | Date | Thu, 21 Mar 2013 12:39:57 +0100 | From | Ingo Molnar <> | Subject | Re: Re: [PATCH -tip ] [BUGFIX] kprobes: Move hash_64() into .text.kprobe section |
| |
* Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
> (2013/03/19 5:57), Timo Juhani Lindfors wrote: > > Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> writes: > >> Thank you for reporting!! > > > > Thanks for fixing these! I spent some time trying to automate the > > process of finding sensitive functions and eventually resorted into > > booting a kvm instance with a minimal initrd to test every single > > function in a clean and reproducible environment. > > > > I found 7 more cases where calling register_kprobe() leads to an instant > > kernel panic: > > > > __flush_tlb_single > > native_flush_tlb > > native_safe_halt > > native_set_pgd > > native_set_pmd > > native_set_pud > > native_write_cr0 > > Ah, right and Great! these native_* things are too fundamental one. > Hmm, curiously, those are defined as inline functions, and > I also couldn't find some of those symbols even with your previous > kconfig. > > > You can see full kernel console output for each function at > > http://lindi.iki.fi/lindi/linux/kprobes/panics_2013-03-18/ > > As you can see, your panic messages, most of them caused GFP. > This may mean that int3 software exception must not happened > on those sites. Not the recursive call. > > Perhaps, I'd better add those native_* things into symbol-name > based blacklist, instead of adding __kprobes, because those > are not related to kprobes recursion.
Blacklists are not really good in general - it's easy for a symbol to be renamed and the blacklist misses them silently ...
symbol name and annotation should go hand in hand.
Thanks,
Ingo
| |