Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759396AbbLCJWi (ORCPT ); Thu, 3 Dec 2015 04:22:38 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:42095 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759189AbbLCJWd (ORCPT ); Thu, 3 Dec 2015 04:22:33 -0500 Subject: Re: [PATCH] arm64: ftrace: stop using kstop_machine to enable/disable tracing To: Will Deacon References: <1448697009-17211-1-git-send-email-huawei.libin@huawei.com> <20151202123654.GC4523@arm.com> CC: , , , , , , From: libin Message-ID: <56600992.4040005@huawei.com> Date: Thu, 3 Dec 2015 17:21:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20151202123654.GC4523@arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.23.78] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.566009C7.005B,ss=1,re=0.000,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: 4f96f4210b4dba10906bd49e1802b521 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2213 Lines: 65 on 2015/12/2 20:36, Will Deacon wrote: > On Sat, Nov 28, 2015 at 03:50:09PM +0800, Li Bin wrote: >> On arm64, kstop_machine which is hugely disruptive to a running >> system is not needed to convert nops to ftrace calls or back, >> because that modifed code is a single 32bit instructions which >> is impossible to cross cache (or page) boundaries, and the used str >> instruction is single-copy atomic. > This commit message is misleading, since the single-copy atomicity > guarantees don't apply to the instruction-side. Instead, the architecture > calls out a handful of safe instructions in "Concurrent modification and > execution of instructions". Right, thank you for your comments. > Now, those safe instructions *do* include NOP, B and BL, so that should > be sufficient for ftrace provided that we don't patch condition codes > (and I don't think we do). Yes, and so far this assumption has no probem, but in order to avoid exceeding these safe insturctions in the future, we can use aarch64_insn_hotpatch_safe() to verify the instruction to determine whether needs stop_machine() to synchronize or use aarch64_insn_patch_text directly. Right or I am missing something? Thanks, Li Bin >> Cc: # 3.18+ > I don't think this is stable material. > > Will > >> Signed-off-by: Li Bin >> --- >> arch/arm64/kernel/ftrace.c | 5 +++++ >> 1 files changed, 5 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c >> index c851be7..9669b33 100644 >> --- a/arch/arm64/kernel/ftrace.c >> +++ b/arch/arm64/kernel/ftrace.c >> @@ -93,6 +93,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec, >> return ftrace_modify_code(pc, old, new, true); >> } >> >> +void arch_ftrace_update_code(int command) >> +{ >> + ftrace_modify_all_code(command); >> +} >> + >> int __init ftrace_dyn_arch_init(void) >> { >> return 0; >> -- >> 1.7.1 >> > . > -- 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/