Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp27445ybt; Tue, 30 Jun 2020 14:05:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwofEDbksiKhjI1hp8mEiOW9CkJpTqeKRGUj0o7ZZzCuV/fJIK64R3d7W7n5gOf5EgG89QX X-Received: by 2002:a05:6402:1346:: with SMTP id y6mr25430853edw.192.1593550703584; Tue, 30 Jun 2020 13:58:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593550703; cv=none; d=google.com; s=arc-20160816; b=sO+6pUJ9AbZRIN87KnrSgWGhsmqNmZk1eOdOfDh4MR7wbIVMltwXnr7gO0r3hXMMui Up26ZLQhwRfG1rvrPE7NzS42QQnY66xNrSwRZPCoA7hyzzh8QKPxcpEQrk2rzxMNL4vX 1IqrngZfs9T7l5Zp2TP9MbzCgFr91Qcdgyyxwto+LZybUluzhphfMF3Vs10ZnjWvmCYH XiGLplr7zXdXIcGHcVgGkcvSVjdpKVlKLrEsLzZVoRb+UmtmL6WvLZOgJ5kuMiz/+20M WToq41JCSz8vr0kXc/stJrMRURzohF4nKKNZWwRu8Kheaz1+koecukhlhVhwGF+S1Ijc k44w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=Ckm+0+kvDbWTLDuUpHAR4S5EGLFyqYk/xfMWw73TCVI=; b=oJoFpimqfrKAajYNvb5onf41EkLjtfJBkxYOREbYkQa3wpBA6SSWUCq6CTku4QPRYq kqNcBYrO3Fze1GDCAwcC8q7VCaoE/h5crRFnqnJFv+/Q3YD4er1zwvCqAyH4v700jyUp FXKRYi4qZ2d9r3zocb/ZGo8b6jFD5x4N2WxJ3sEOX8w2KAgZwRDO1apDb/QpPotlDiAt D7Q3BNdu6oYCmn3DypcqTlyp8dp3tTrBPjeJmZxKpwDE4pKPFMQIyATdIXMOUz1eZyU3 ejX8XF4Vxsw24buba/VtkKpCQYqKlTfpY9bG52A30ALvfRjaD6OL7P8Zv1PCK7YnHnCA 8w/Q== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h25si2496662edv.231.2020.06.30.13.58.00; Tue, 30 Jun 2020 13:58:23 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728460AbgF3Tss (ORCPT + 99 others); Tue, 30 Jun 2020 15:48:48 -0400 Received: from foss.arm.com ([217.140.110.172]:32904 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728407AbgF3Tsq (ORCPT ); Tue, 30 Jun 2020 15:48:46 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 925C3106F; Tue, 30 Jun 2020 12:48:45 -0700 (PDT) Received: from seattle-bionic.arm.com.Home (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A45CE3F73C; Tue, 30 Jun 2020 12:48:44 -0700 (PDT) From: Oliver Swede To: Will Deacon , Catalin Marinas Cc: Robin Murphy , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 02/14] arm64: kprobes: Drop open-coded exception fixup Date: Tue, 30 Jun 2020 19:48:10 +0000 Message-Id: <20200630194822.1082-3-oli.swede@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200630194822.1082-1-oli.swede@arm.com> References: <20200630194822.1082-1-oli.swede@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Robin Murphy The short-circuit call to fixup_exception() from kprobe_fault_handler() poses a problem now that the former wants to consume the fault address too, since the common kprobes API offers us no way to pass it through. Fortunately, however, it works out to be unnecessary: - uaccess instructions themselves are not probeable, so at most we should only ever expect to take a fixable fault from the pre or post handlers. - the pre and post handler run with preemption disabled, thus for any fault they may cause, an unhandled return from kprobe_page_fault() will proceed directly to __do_kernel_fault() thanks to the faulthandler_disabled() check. - __do_kernel_fault() will immediately call fixup_exception() unless we're in an EL1 instruction abort, and if we've somehow taken one of those on what we think is the middle of a uaccess routine, then the world is already very on fire. Thus we can reasonably drop the call from kprobe_fault_handler() and leave uaccess fixups to the regular flow. Signed-off-by: Robin Murphy Signed-off-by: Oliver Swede --- arch/arm64/kernel/probes/kprobes.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c index d1c95dcf1d78..771635360110 100644 --- a/arch/arm64/kernel/probes/kprobes.c +++ b/arch/arm64/kernel/probes/kprobes.c @@ -334,13 +334,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr) */ if (cur->fault_handler && cur->fault_handler(cur, regs, fsr)) return 1; - - /* - * In case the user-specified fault handler returned - * zero, try to fix up. - */ - if (fixup_exception(regs)) - return 1; } return 0; } -- 2.17.1