On Tue, Dec 24, 2013 at 4:32 PM, Masami Hiramatsu <masami.hiramatsu...@hitachi.com> wrote: > (2013/12/24 15:39), Jovi Zhangwei wrote: >> On Mon, Dec 23, 2013 at 6:59 PM, Masami Hiramatsu >> <masami.hiramatsu...@hitachi.com> wrote: >>> (2013/12/23 13:51), Jovi Zhangwei wrote: >>>> On Fri, Dec 20, 2013 at 5:21 PM, Masami Hiramatsu >>>> <masami.hiramatsu...@hitachi.com> wrote: >>>>> (2013/12/20 17:31), Jovi Zhangwei wrote: >>>>>> On Fri, Dec 20, 2013 at 12:42 PM, Masami Hiramatsu >>>>>> <masami.hiramatsu...@hitachi.com> wrote: >>>>>>> (2013/12/20 12:07), Jovi Zhangwei wrote: >>>>>>>> On Fri, Dec 20, 2013 at 10:37 AM, Masami Hiramatsu >>>>>>>> <masami.hiramatsu...@hitachi.com> wrote: >>>>>>>>> Hi Jovi, >>>>>>>>> >>>>>>>>> (2013/12/19 18:37), Jovi Zhangwei wrote: >>>>>>>>>> Hi Masami, >>>>>>>>>> >>>>>>>>>> On Thu, Dec 19, 2013 at 5:04 PM, Masami Hiramatsu >>>>>>>>>> <masami.hiramatsu...@hitachi.com> wrote: >>>>>>>>>>> memcpy/memset functions are fundamental functions and >>>>>>>>>>> those are involved in kprobe's exception handling. >>>>>>>>>>> Prohibit probing on them to avoid kernel crash. >>>>>>>>>>> >>>>>>>>>> Would you please let me know the LKML link of that bugfix, I cannot >>>>>>>>>> find it in my LKML fold. >>>>>>>>> >>>>>>>>> Yeah, that was found in my testing environment. >>>>>>>>> >>>>>>>>>> No objection on this patch. :) just want to know more, It seems there >>>>>>>>>> have no problem to probe memcpy in my box, maybe I didn't hit the >>>>>>>>>> crash code path. >>>>>>>>> >>>>>>>>> Ah, I see. Originally the problem happened when I put a probe on >>>>>>>>> __memcpy. And it looks the instances of memcpy and __memcpy are >>>>>>>>> same on x86-64. Thus I decided to blacklist both. (memset/__memset >>>>>>>>> too) >>>>>>>>> Have you ever tried to probe __memcpy on your box? >>>>>>>>> >>>>>>>> Hmm, still no crash, __memcpy and __memset are both tested. >>>>>>>> >>>>>>>> I use below kprobe related config: >>>>>>>> >>>>>>>> CONFIG_KPROBES=y >>>>>>>> CONFIG_JUMP_LABEL=y >>>>>>>> CONFIG_OPTPROBES=y >>>>>>>> CONFIG_KPROBES_ON_FTRACE=y >>>>>>> >>>>>>> Hmm, I've added some debugging options. >>>>>>> >>>>>>> CONFIG_SLUB_DEBUG=y >>>>>>> CONFIG_X86_DEBUGCTLMSR=y >>>>>>> CONFIG_PNP_DEBUG_MESSAGES=y >>>>>>> CONFIG_DEBUG_INFO=y >>>>>>> CONFIG_DEBUG_FS=y >>>>>>> CONFIG_DEBUG_KERNEL=y >>>>>>> CONFIG_DEBUG_STACK_USAGE=y >>>>>>> CONFIG_DEBUG_MEMORY_INIT=y >>>>>>> CONFIG_DEBUG_STACKOVERFLOW=y >>>>>>> CONFIG_DEBUG_SPINLOCK=y >>>>>>> CONFIG_DEBUG_MUTEXES=y >>>>>>> CONFIG_DEBUG_LOCK_ALLOC=y >>>>>>> CONFIG_DEBUG_LOCKDEP=y >>>>>>> CONFIG_DEBUG_BUGVERBOSE=y >>>>>>> CONFIG_DEBUG_RODATA=y >>>>>>> CONFIG_DEBUG_BOOT_PARAMS=y >>>>>>> >>>>>>> I guess some of them might cause it. >>>>>>> >>>>>> I recompiled the kernel with those config enabled, unfortunately still >>>>>> no crash, >>>>>> I tested on 3.13.0-rc4, a fedora kvm box. >>>>> >>>>> Hmm, it's very odd. I'm running 3.13.0-rc4 x86-64 on the fedora >>>>> kvm box too. here is the full of my kconfig. >>>>> >>>> That configuration is still working for me, no crash for memcpy kprobe >>>> test. >>> >>> Would you do __memcpy test? or memcpy test? I only had a crash on the >>> __memcpy(__memset). >>> >> Still no crash, use your kernel config. >> memcpy and __memcpy have same address in /proc/kallsyms. >> >> Looks like a interesting problem. > > Agreed. In my case, those have same address, but only probing > __memcpy caused a kernel crash. I'm not sure why, but it is > safe to disable probing on it. > Shall we need dig further to address the root cause? IMO, the kprobe should act same behavior when given same probe address, but it's look so weird in your box. :)
Thanks, Jovi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
