Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp233776pxv; Thu, 8 Jul 2021 19:48:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVL5MqX0IbF7QSbxQfwa19VTkHMYR93PPuvq4Dy0azgq8H3XWAoE/iTyc2UzXJm3y7krmf X-Received: by 2002:a92:dc87:: with SMTP id c7mr7292944iln.306.1625798921376; Thu, 08 Jul 2021 19:48:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625798921; cv=none; d=google.com; s=arc-20160816; b=hlkLEt2LqKG3v9SOyw+MWb65QCWvabfy5mMrWyRTTAmdotN9KD8Lcpxf/8u85BCHCC vXmoLPoFvpEmsUNu7KLLLcL+fPsaymq+3NLMiolQ/bE7YtASzS7F7w8paBe+Z9KMrPIz YDhorkBeIEui4j2fJYgmDA7gN1cBccBV25eNyMdzH8E8s40Ai/kL0pFVH+YHG/jpAsqz hYUhJRR3Pepoihh4btFVXv60+bquTDekYgXv+pxraLSWZiwEPikveHgCt4VVviF3Likv oN+mtnbnvY5nOSTag5cJ4dyxoh0+kz7ZyU2YxyYuAPEYogNSzD2pv39fa9C0FlsWNDsr Mb6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=fJhxIWZK34X35CsCHY0uPzSIIBgOIug+VnqoD1nyLPY=; b=EFJXBQB3yM5+Wpjd15jLQHO2a/YPfIjU2/XByexaf5qBm3enGeiI3zwC5W4Z2wC9q/ dfm94j3JYEOxuvseXZYhDETi36AwnAoNcYp0Z7So/X80PoZ6uzi2c+xwbbTf8bM7bScp 4AkmL76cM/sxk4Zw+C1aAn5k0HfBdJFzPXawkEOe6KOIQwhcTvMTI/mfFxn52tYQ2dr8 LM3sLeEaSLuMqlMSjkvSMVX1JPkqtv74nwxdUEmcJTVw+XTYaIZxQt5ed/m621gcvcr6 nTda89yRHxfwL8Gpz4dXd+AFdi3oSu1ihan6ozZA73nauQCxWt+4yBtdqcDX4JAIRdjp AQeQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j20si3695608jak.112.2021.07.08.19.48.29; Thu, 08 Jul 2021 19:48:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230323AbhGICtQ (ORCPT + 99 others); Thu, 8 Jul 2021 22:49:16 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:11232 "EHLO szxga08-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229637AbhGICtP (ORCPT ); Thu, 8 Jul 2021 22:49:15 -0400 Received: from dggeme765-chm.china.huawei.com (unknown [172.30.72.53]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4GLcq01Ykrz1CGSP; Fri, 9 Jul 2021 10:41:00 +0800 (CST) Received: from DESKTOP-E0KHRBE.china.huawei.com (10.67.103.82) by dggeme765-chm.china.huawei.com (10.3.19.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 9 Jul 2021 10:46:30 +0800 From: Shaobo Huang To: CC: , , , , , , , , , , , , Subject: [PATCH 4.4.y] arm: kprobes: Allow to handle reentered kprobe on single-stepping Date: Fri, 9 Jul 2021 10:46:30 +0800 Message-ID: <20210709024630.22268-1-huangshaobo6@huawei.com> X-Mailer: git-send-email 2.21.0.windows.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.103.82] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggeme765-chm.china.huawei.com (10.3.19.111) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Masami Hiramatsu commit f3fbd7ec62dec1528fb8044034e2885f2b257941 upstream This is arm port of commit 6a5022a56ac3 ("kprobes/x86: Allow to handle reentered kprobe on single-stepping") Since the FIQ handlers can interrupt in the single stepping (or preparing the single stepping, do_debug etc.), we should consider a kprobe is hit in the NMI handler. Even in that case, the kprobe is allowed to be reentered as same as the kprobes hit in kprobe handlers (KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE). The real issue will happen when a kprobe hit while another reentered kprobe is processing (KPROBE_REENTER), because we already consumed a saved-area for the previous kprobe. Signed-off-by: Masami Hiramatsu Signed-off-by: Jon Medhurst Fixes: 24ba613c9d6c ("ARM kprobes: core code") Cc: stable@vger.kernel.org #v2.6.25~v4.11 Signed-off-by: huangshaobo --- arch/arm/probes/kprobes/core.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c index 3eb018fa1a1f..c3362ddd6c4c 100644 --- a/arch/arm/probes/kprobes/core.c +++ b/arch/arm/probes/kprobes/core.c @@ -270,6 +270,7 @@ void __kprobes kprobe_handler(struct pt_regs *regs) switch (kcb->kprobe_status) { case KPROBE_HIT_ACTIVE: case KPROBE_HIT_SSDONE: + case KPROBE_HIT_SS: /* A pre- or post-handler probe got us here. */ kprobes_inc_nmissed_count(p); save_previous_kprobe(kcb); @@ -278,6 +279,11 @@ void __kprobes kprobe_handler(struct pt_regs *regs) singlestep(p, regs, kcb); restore_previous_kprobe(kcb); break; + case KPROBE_REENTER: + /* A nested probe was hit in FIQ, it is a BUG */ + pr_warn("Unrecoverable kprobe detected at %p.\n", + p->addr); + /* fall through */ default: /* impossible cases */ BUG(); -- 2.12.3