Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965466AbbEMT6s (ORCPT ); Wed, 13 May 2015 15:58:48 -0400 Received: from mail-qk0-f182.google.com ([209.85.220.182]:36373 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964916AbbEMT6p (ORCPT ); Wed, 13 May 2015 15:58:45 -0400 Message-ID: <5553ACF2.2080802@linaro.org> Date: Wed, 13 May 2015 15:58:42 -0400 From: David Long User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: William Cohen , Masami Hiramatsu , Will Deacon CC: "linux-arm-kernel@lists.infradead.org" , Russell King , "sandeepa.s.prabhu@gmail.com" , Steve Capper , Catalin Marinas , "Jon Medhurst (Tixy)" , Ananth N Mavinakayanahalli , Anil S Keshavamurthy , "davem@davemloft.net" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v6 0/6] arm64: Add kernel probes (kprobes) support References: <1429561187-3661-1-git-send-email-dave.long@linaro.org> <55363791.4070706@hitachi.com> <553AB222.50609@redhat.com> <553EF74D.8020706@redhat.com> <20150429102346.GK8236@arm.com> <55442BFA.50101@redhat.com> <554851CB.2010909@linaro.org> <20150505154830.GI1550@arm.com> <55519583.9020507@linaro.org> <5551F693.8050100@redhat.com> <555317E8.2000502@hitachi.com> <555370B9.2070203@redhat.com> In-Reply-To: <555370B9.2070203@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3468 Lines: 68 On 05/13/15 11:41, William Cohen wrote: > On 05/13/2015 05:22 AM, Masami Hiramatsu wrote: >> On 2015/05/12 21:48, William Cohen wrote: > >>> Hi Dave, >>> >>> In some of the previous diagnostic output it looked like things would go wrong >>> in the entry.S when the D bit was cleared and the debug interrupts were >>> unmasksed. I wonder if some of the issue might be due to the starting the >>> kprobe for the trampoline, but leaving things in an odd state when another >>> set of krpobe/kretporbes are hit when the trampoline is running. >> >> Hmm, does this mean we have a trouble if a user kprobe handler calls the >> function which is probed by other kprobe? Or, is this just a problem >> only for kretprobes? > > Hi Masami, > > I wrote an example based off of sample/kprobes/kprobes_sample.c to force the reentry issue for kprobes (the attached kprobe_rentry_example.c). That seemed to run fine. I think the reason that the trampoline handler got into trouble is because of the reset_current_kprobe() before the possible call to kfree, but I haven't verified it. It seems like that should be at the end of trampoline handler just before the return. Other architectures have similar trampoline handlers, so I am surprised that the other architectures haven't encountered this issue with kretprobes. Maybe this is due to specific of arm64 exception handling. > > # modprobe kprobe_reentry_example > [ 909.617295] Planted kprobe at fffffe00000b7b34 > [ 909.623873] Planted kprobe at fffffe000032d34c > # rmmod kprobe_reentry_example > [ 1482.647504] kprobe at fffffe00000b7b34 unregistered > [ 1482.687506] kprobe at fffffe000032d34c unregistered > [ 1482.692361] y = 42 > [ 1482.694361] z = 0 > # grep \ int_sqrt$ /proc/kallsyms > fffffe000032d34c T int_sqrt > # grep \ do_fork$ /proc/kallsyms > fffffe00000b7b34 T do_fork > I actually have been doing exactly the same thing. I was not able to provoke a failure in either the pre or post handler when having them call to another kprobe'd (dummy) function. However it does look to me like it's reentering the exception handler firstly at the second software breakpoint and then (shortly after returning from that) with a single-step. That's what you would expect but I *thought* neither of those cases was allowed. It does not call either the pre or post handler in the dummy function. I would expect this to be an issue for a kretprobe pre handler too, although I've yet to test this. >> >>> As Dave >>> mentioned the proposed trampoline patch avoids using a kprobe in the >>> trampoline and directly calls the trampoline handler. Attached is the >>> current version of the patch which was able to run the systemtap testsuite. >>> Systemtap does exercise the kprobe/kretprobe infrastructure, but it would >>> be good to have additional raw kprobe tests to check that kprobe reentry >>> works as expected. >> >> Actually, Will's patch looks like the same thing what I did on x86, >> as the kretprobe-booster. So I'm OK for that. But if the above problem >> is not solved, we need to fix that, since kprobes can be used from >> different sources. > > The patch should look similar to the x86 code. The x86 code was used as a model. > > -Will > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/