From patchwork Wed Mar 4 02:24:55 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Nan X-Patchwork-Id: 5928181 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 698A59F380 for ; Wed, 4 Mar 2015 02:29:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 81DF02034A for ; Wed, 4 Mar 2015 02:29:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9889120260 for ; Wed, 4 Mar 2015 02:29:49 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1YSz14-0003wU-Tp; Wed, 04 Mar 2015 02:26:30 +0000 Received: from szxga03-in.huawei.com ([119.145.14.66]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1YSz0x-0003hA-TX for linux-arm-kernel@lists.infradead.org; Wed, 04 Mar 2015 02:26:25 +0000 Received: from 172.24.2.119 (EHLO szxeml425-hub.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id BCO89165; Wed, 04 Mar 2015 10:25:24 +0800 (CST) Received: from [127.0.0.1] (10.111.69.129) by szxeml425-hub.china.huawei.com (10.82.67.180) with Microsoft SMTP Server id 14.3.158.1; Wed, 4 Mar 2015 10:25:16 +0800 Message-ID: <54F66CF7.9010606@huawei.com> Date: Wed, 4 Mar 2015 10:24:55 +0800 From: Wang Nan User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Petr Mladek Subject: Re: [PATCH 3/3] early kprobes: x86: don't try to recover ftraced instruction before ftrace get ready. References: <1425306312-3437-1-git-send-email-wangnan0@huawei.com> <1425359345-38714-1-git-send-email-wangnan0@huawei.com> <1425359345-38714-4-git-send-email-wangnan0@huawei.com> <20150303170633.GG3703@dhcp128.suse.cz> In-Reply-To: <20150303170633.GG3703@dhcp128.suse.cz> X-Originating-IP: [10.111.69.129] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.54F66D16.0001, ss=1, re=0.001, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b47ea4725b28ab5ffab15679ff6985bc X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150303_182624_541113_F5F3AD0B X-CRM114-Status: GOOD ( 21.31 ) X-Spam-Score: -2.3 (--) Cc: tixy@linaro.org, linux@arm.linux.org.uk, x86@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, lizefan@huawei.com, masami.hiramatsu.pt@hitachi.com, mingo@elte.hu, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 2015/3/4 1:06, Petr Mladek wrote: > On Tue 2015-03-03 13:09:05, Wang Nan wrote: >> Before ftrace convertin instruction to nop, if an early kprobe is >> registered then unregistered, without this patch its first bytes will >> be replaced by head of NOP, which may confuse ftrace. >> >> Actually, since we have a patch which convert ftrace entry to nop >> when probing, this problem should never be triggered. Provide it for >> safety. >> >> Signed-off-by: Wang Nan >> --- >> arch/x86/kernel/kprobes/core.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c >> index 87beb64..c7d304d 100644 >> --- a/arch/x86/kernel/kprobes/core.c >> +++ b/arch/x86/kernel/kprobes/core.c >> @@ -225,6 +225,9 @@ __recover_probed_insn(kprobe_opcode_t *buf, unsigned long addr) >> struct kprobe *kp; >> unsigned long faddr; >> >> + if (!kprobes_on_ftrace_initialized) >> + return addr; > > This is not correct. The function has to return a buffer with the original > code also when it is modified by normal kprobes. If it is a normal > Kprobe, it reads the current code and replaces the first byte (INT3 > instruction) with the saved kp->opcode. > >> + >> kp = get_kprobe((void *)addr); >> faddr = ftrace_location(addr); > > IMHO, the proper fix might be to replace the above line with > > if (kprobes_on_ftrace_initialized) > faddr = ftrace_location(addr); > else > faddr = 0UL; > > By other words, it might pretend that it is not a ftrace location > when the ftrace is not ready yet. > Thanks for your reply. I'll follow your suggection in my next version. I change it as follow to enable the checking. > Or is the code modified another special way when it is a ftrace location but > ftrace has not been initialized yet? > > Best Regards, > Petr > >> /* >> -- >> 1.8.4 >> >> -- >> 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/ diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c index 4e3d5a9..3241677 100644 --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -234,6 +234,20 @@ __recover_probed_insn(kprobe_opcode_t *buf, unsigned long addr) */ if (WARN_ON(faddr && faddr != addr)) return 0UL; + + /* + * If ftrace is not ready yet, pretend this is not an ftrace + * location, because currently the target instruction has not + * been replaced by a NOP yet. When ftrace trying to convert + * it to NOP, kprobe should be notified and the kprobe data + * should be fixed at that time. + * + * Since it is possible that an early kprobe already on that + * place, don't return addr directly. + */ + if (likely(kprobes_on_ftrace_initialized)) + faddr = 0UL; + /* * Use the current code if it is not modified by Kprobe * and it cannot be modified by ftrace