Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp322729rwb; Mon, 26 Sep 2022 19:54:04 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7MCJ6lXiWgYtScv242pJmxfSI77NHHxdVLrsidnlSukNUir3sOIpI94EjsJBkRGRw7RHPw X-Received: by 2002:a17:90a:c38d:b0:203:5db4:577a with SMTP id h13-20020a17090ac38d00b002035db4577amr2055965pjt.69.1664247244475; Mon, 26 Sep 2022 19:54:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664247244; cv=none; d=google.com; s=arc-20160816; b=jZ5eDWyA81Yr0gEciXx2iN2j6OFLD62blO4YfEgEVAk40pXumke6VLRv2RLDCA13ez 4ZoWk80k8hz7PZZqkgb+3kift3vNm3B997HLWpY/izpzOW1RydvJv3NIKNKylAEMM4qb RQW0+TkRD0pdsww+cHxRJNRtXUdbnoXPuXL2U0BZkcOJZoC6mb5g9Pzhv9Fmfq4XcI9j cZClcyxsM4EmxvuoJENymyo5+loM98pmIJ5+qY8XWngfQo7S9vDkfH+wkdUy2IZDu/Xg EaXvNdL8ogqkkg+Sh/To6PK1B6nUWJ/ysjuc2hZS7rK+l/vi5VuL9OZ40MOhL1r/CFJf SDxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=Q27OYxm8el7RDOtv4mn8Wpoux612CSB315ZNR2ifucY=; b=KF8qGP72qc6nITlz6aS1xJKU2SKvBUVY7ubDOzfVEIkP/lYLxQq5AkMaxxbgL3s5Mc 5OaLcsBuwangRQppZyP4dFOvY6HSCtXcC8Djb4ccNBjhquK8vz7J+V2m07Wd/HUYMTfe Q6X8jjYOBu4uYq810+NI9e2JTVj7fLafKHis6WD53/ww1QPQkpsVkd5rdZCf5lAFA6jy dd6RpCyZglkBJoOeswT9PvhuOb0yPEEUMcNmzZI/YYZTOhO/kqZ0a8PpF7RfDvn0P2sm N5leCvC1jUSWVQcd9Tk/YQw6Q4uY9EFG/M1NABtp+b+4Je9e6GfNfdkuqUDtSDYqJ+aI xWrg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mi17-20020a17090b4b5100b001fd73f8193csi643271pjb.10.2022.09.26.19.53.53; Mon, 26 Sep 2022 19:54:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230266AbiI0C2v (ORCPT + 99 others); Mon, 26 Sep 2022 22:28:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230179AbiI0C2Y (ORCPT ); Mon, 26 Sep 2022 22:28:24 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 02166AB19A; Mon, 26 Sep 2022 19:28:24 -0700 (PDT) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Mc3Pg1x01zpVN2; Tue, 27 Sep 2022 10:25:27 +0800 (CST) Received: from huawei.com (10.67.174.53) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 27 Sep 2022 10:28:21 +0800 From: Liao Chang To: , , , , , , , , , , CC: , , , Subject: [PATCH 3/3] arm64/kprobe: Optimize the performance of patching single-step slot Date: Tue, 27 Sep 2022 10:24:35 +0800 Message-ID: <20220927022435.129965-4-liaochang1@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220927022435.129965-1-liaochang1@huawei.com> References: <20220927022435.129965-1-liaochang1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.174.53] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemi500012.china.huawei.com (7.221.188.12) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Single-step slot would not be used until kprobe is enabled, that means no race condition occurs on it under SMP, hence it is safe to pacth ss slot without stopping machine. Since I and D caches are coherent within single-step slot from aarch64_insn_patch_text_nosync(), hence no need to do it again via flush_icache_range(). Acked-by: Will Deacon Acked-by: Masami Hiramatsu (Google) Signed-off-by: Liao Chang --- arch/arm64/kernel/probes/kprobes.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c index d1d182320245..c9e4d0720285 100644 --- a/arch/arm64/kernel/probes/kprobes.c +++ b/arch/arm64/kernel/probes/kprobes.c @@ -44,13 +44,28 @@ post_kprobe_handler(struct kprobe *, struct kprobe_ctlblk *, struct pt_regs *); static void __kprobes arch_prepare_ss_slot(struct kprobe *p) { kprobe_opcode_t *addr = p->ainsn.api.insn; - void *addrs[] = {addr, addr + 1}; - u32 insns[] = {p->opcode, BRK64_OPCODE_KPROBES_SS}; - /* prepare insn slot */ - aarch64_insn_patch_text(addrs, insns, 2); - - flush_icache_range((uintptr_t)addr, (uintptr_t)(addr + MAX_INSN_SIZE)); + /* + * Prepare insn slot, Mark Rutland points out it depends on a coupe of + * subtleties: + * + * - That the I-cache maintenance for these instructions is complete + * *before* the kprobe BRK is written (and aarch64_insn_patch_text_nosync() + * ensures this, but just omits causing a Context-Synchronization-Event + * on all CPUS). + * + * - That the kprobe BRK results in an exception (and consequently a + * Context-Synchronoization-Event), which ensures that the CPU will + * fetch thesingle-step slot instructions *after* this, ensuring that + * the new instructions are used + * + * It supposes to place ISB after patching to guarantee I-cache maintenance + * is observed on all CPUS, however, single-step slot is installed in + * the BRK exception handler, so it is unnecessary to generate + * Contex-Synchronization-Event via ISB again. + */ + aarch64_insn_patch_text_nosync(addr, p->opcode); + aarch64_insn_patch_text_nosync(addr + 1, BRK64_OPCODE_KPROBES_SS); /* * Needs restoring of return address after stepping xol. -- 2.17.1