Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2307522pxk; Mon, 14 Sep 2020 09:47:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZ+04cp6U7pqnG27Pvv0fb0PYxBZfXIjLdORNyHoLP+/qknntZlMLA8kceghYPPJkIjFdf X-Received: by 2002:a05:6402:b0f:: with SMTP id bm15mr17822479edb.388.1600102055517; Mon, 14 Sep 2020 09:47:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600102055; cv=none; d=google.com; s=arc-20160816; b=SHIgWGt61Cf+1hKh+fDLYNlFL5R7XEGdZ+yDqC2Jh2PqeWre162gYqzVx6HR/iHIqq Wt7H6hjDtkIlH5I4D138T6iG3NTjAtvyKcCB3guSFOsNfjdZ01wOo6xHB3Zf8cFCAqgm F2tFBYUORZM5QYuci/rOfjevSFNv02L4HvW8AMU4krv309n9tAOmh4+d+pWmV4sqrUq4 qNWZe5DqnSw6Z6dIZs/yb6R8OjSnr6A1DDHb1j3eEG6bNY53BYuSFEbRhJ6v8AwWDQ7Q IBZUq0njQvCWkuqbTRuoxfxSFspaxWVzySL/ogjDMoUsqmMm/5GsB/Eh7Og8ox6E6lb8 yExw== 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=mmONMf9+AkeksGGlPZ9jHnO72t9Movk0EBCCxKiusy4=; b=HENluyG/TvoM1xlgfRMQFU0MF/LMyyW5hQs2E/d5ANYYuc38J1BrsQjofpWG9sGLr5 6rdDZOdEbjACmtMM0/t2n84DKcqLRv+gqMqSv71UbjMSsyW6AlkpuGSwjDd01nIv0ssY xvzZaaTjjwivMYFsojQRL493croxHL/vlW33Pgu+D6SHQcwMXtVXnkCdDD0AGb/X5Eef LRrKYOkzRqqaGQyRL28tw6oRq09L4vTUyNRXaJnQJKRdJyLFCOwvfu4NOHvRXPFUkd9J ft8AD9YPw0Kv5PhBFC6cva8wAUjWoNLDcrNqDw3xD9Rz3twp67e7DpysIhxtwXWUMQVw Z+0Q== 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 nx23si7779997ejb.291.2020.09.14.09.47.13; Mon, 14 Sep 2020 09:47:35 -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 S1725992AbgINQoi (ORCPT + 99 others); Mon, 14 Sep 2020 12:44:38 -0400 Received: from foss.arm.com ([217.140.110.172]:39600 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726064AbgINPKn (ORCPT ); Mon, 14 Sep 2020 11:10:43 -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 3D2B41396; Mon, 14 Sep 2020 08:10:37 -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 3CDBC3F718; Mon, 14 Sep 2020 08:10:36 -0700 (PDT) From: Oliver Swede To: catalin.marinas@arm.com, will@kernel.org Cc: robin.murphy@arm.com, linux-arm-kernel@lists.indradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 02/14] arm64: kprobes: Drop open-coded exception fixup Date: Mon, 14 Sep 2020 15:09:46 +0000 Message-Id: <20200914150958.2200-3-oli.swede@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200914150958.2200-1-oli.swede@arm.com> References: <20200914150958.2200-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 5290f17a4d80..c54c8252b32f 100644 --- a/arch/arm64/kernel/probes/kprobes.c +++ b/arch/arm64/kernel/probes/kprobes.c @@ -328,13 +328,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