Messages in this thread | | | Date | Thu, 21 Mar 2013 22:23:33 +0900 | From | Masami Hiramatsu <> | Subject | Re: Re: Re: [PATCH -tip ] [BUGFIX] kprobes: Move hash_64() into .text.kprobe section |
| |
(2013/03/21 20:39), Ingo Molnar wrote: > > * 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 ...
Ah, right.
> > symbol name and annotation should go hand in hand.
Thus, I think we'd better moving __kprobes into compiler.h first.
Anyway, I'm still waiting for the actual kconfig from Timo, because I couldn't reproduce the problem yet (no such symbols).
Thank you,
-- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |