From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75377C433F5 for ; Wed, 13 Oct 2021 12:12:21 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 251F860E53 for ; Wed, 13 Oct 2021 12:12:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 251F860E53 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date:Subject:Cc:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=ChCdH60hRHxHgqY7Ww0yRCVC3fNfYsJgIWd+migp46o=; b=Vr2YJppPix648z bguKbrwldif5FDgrkUXd0QqmbUP2tOeJny5jmeqDG8qBOG8IIJGWcwuARlHavGHsWq9DHRRaA0J1p mWmxlLqp5zd5bfvXcyKh11qDNftVgcwo9zVy15LIeB9fpTzjGMSHknpaytpUpY6OFS/5uXZ/5EcMl gLXFAP9X1za9COZk959Gx6tjms4BhdiJJLj/5/Nrx3mA4qdZCf04OdlN0DQ+Huensdsshi1L0mhWA 4pMRBYwFDLtoWDyhbtnUbj4shSWH9ToJpumpgVxVvoHYEkVip1yFjGMezuep1EOHRCACsYUwlIsoa OlTrcdVa0EJm8s8qDjYQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mad4k-00GT8x-Ae; Wed, 13 Oct 2021 12:09:39 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mac0b-00G9rx-It for linux-arm-kernel@lists.infradead.org; Wed, 13 Oct 2021 11:01:19 +0000 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 8C7BB13A1; Wed, 13 Oct 2021 04:01:15 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 57C873F70D; Wed, 13 Oct 2021 04:01:13 -0700 (PDT) From: Mark Rutland To: linux-arm-kernel@lists.infradead.org Cc: alexandru.elisei@arm.com, andrii@kernel.org, ardb@kernel.org, ast@kernel.org, broonie@kernel.org, catalin.marinas@arm.com, daniel@iogearbox.net, dvyukov@google.com, james.morse@arm.com, jean-philippe@linaro.org, jpoimboe@redhat.com, mark.rutland@arm.com, maz@kernel.org, peterz@infradead.org, robin.murphy@arm.com, suzuki.poulose@arm.com, will@kernel.org Subject: [PATCH 00/13] arm64: extable: remove anonymous out-of-line fixups Date: Wed, 13 Oct 2021 12:00:46 +0100 Message-Id: <20211013110059.10324-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.11.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211013_040117_743645_2C8FF7B2 X-CRM114-Status: GOOD ( 17.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org We recently realised that out-of-line extable fixups cause a number of problems for backtracing (mattering both for developers and for RELIABLE_STACKTRACE and LIVEPATCH). Dmitry spotted a confusing backtrace, which we identified was due to problems with unwinding fixups, as summarized in: https://lore.kernel.org/linux-arm-kernel/20210927171812.GB9201@C02TD0UTHF1T.local/ The gist is that while backtracing through a fixup, the fixup gets symmbolized as an offset from the nearest prior symbol (which happens to be `__entry_tramp_text_end`), and we the backtrace misses the function that was being fixed up (because the fixup handling adjusts the PC, then the fixup does a direct branch back to the original function). We can't reliably map from an arbitrary PC in the fixup text back to the original function. The way we create fixups is a bit unfortunate: most fixups are generated from common templates, and only differ in register to be poked and the address to branch back to, leading to redundant copies of the same logic that must pollute Since the fixups are all written in assembly, and duplicated for each fixup site, we can only perform very simple fixups, and can't handle any complex triage that we might need for some exceptions (e.g. MTE faults). This series address these concerns by getting rid of the out-of-line anonymous fixup logic: * For plain assembly functions, we move the fixup into the body of the function, after the usual return, as we already do for our cache routines. This simplifies the source code, and only adds a handful of instructions to the main body of `.text`. This is handled by the first three patches, which I think are trivial and could be queued regardless of the rest of the series. * For inline assembly, we add specialised handlers which run in exception context to update registers, then adjust the PC *within* the faulting function. This requires some new glue to capture the handler and metadata in struct exception_table_entry (costing 32 bits per fixup), but for any non-trivial fixup (which is all of the inline asm cases), this removes at least two instructions of out-of-line fixup. As the fixups are now handled from C code in exception context, we can more easily extend these in future with more complex triage if necessary. Overall, this doesn't have an appreciable impact on Image size (in local testing the size of the Image was identical before/after), but does shift the boundary between .text and .ordata, making .text smaller and .rodata bigger. .text somewhat while growing .rodata somewhat. I've tested this with both GCC and clang (including with clang CFI), and everything is working as expected. Other than changes to backtracing, there should be no functional change as a result of this series. Thanks Mark. Mark Rutland (13): arm64: lib: __arch_clear_user(): fold fixups into body arm64: lib: __arch_copy_from_user(): fold fixups into body arm64: lib: __arch_copy_to_user(): fold fixups into body arm64: kvm: use kvm_exception_table_entry arm64: factor out GPR numbering helpers arm64: gpr-num: support W registers arm64: extable: consolidate definitions arm64: extable: make fixup_exception() return bool arm64: extable: use `ex` for `exception_table_entry` arm64: extable: add `type` and `data` fields arm64: extable: add a dedicated uaccess handler arm64: extable: add load_unaligned_zeropad() handler arm64: vmlinux.lds.S: remove `.fixup` section arch/arm64/include/asm/asm-extable.h | 95 +++++++++++++++++++++++++++++++++ arch/arm64/include/asm/asm-uaccess.h | 7 ++- arch/arm64/include/asm/assembler.h | 29 +--------- arch/arm64/include/asm/extable.h | 23 +++++--- arch/arm64/include/asm/futex.h | 25 +++------ arch/arm64/include/asm/gpr-num.h | 26 +++++++++ arch/arm64/include/asm/kvm_asm.h | 7 +-- arch/arm64/include/asm/sysreg.h | 25 +++------ arch/arm64/include/asm/uaccess.h | 26 ++------- arch/arm64/include/asm/word-at-a-time.h | 21 ++------ arch/arm64/kernel/armv8_deprecated.c | 12 ++--- arch/arm64/kernel/traps.c | 9 +--- arch/arm64/kernel/vmlinux.lds.S | 1 - arch/arm64/kvm/hyp/include/hyp/switch.h | 10 ++-- arch/arm64/lib/clear_user.S | 9 ++-- arch/arm64/lib/copy_from_user.S | 7 +-- arch/arm64/lib/copy_to_user.S | 7 +-- arch/arm64/mm/extable.c | 85 +++++++++++++++++++++++++---- arch/arm64/net/bpf_jit_comp.c | 9 ++-- scripts/sorttable.c | 30 +++++++++++ 20 files changed, 306 insertions(+), 157 deletions(-) create mode 100644 arch/arm64/include/asm/asm-extable.h create mode 100644 arch/arm64/include/asm/gpr-num.h -- 2.11.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel