All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	will@kernel.org, james.morse@arm.com
Cc: mark.rutland@arm.com, keescook@chromium.org, maz@kernel.org,
	broonie@kernel.org, labbott@redhat.com, robin.murphy@arm.com,
	julien.thierry.kdev@gmail.com, alex.popov@linux.com
Subject: [PATCH 01/17] arm64: entry: mark all entry code as notrace
Date: Wed,  8 Jan 2020 18:56:18 +0000	[thread overview]
Message-ID: <20200108185634.1163-2-mark.rutland@arm.com> (raw)
In-Reply-To: <20200108185634.1163-1-mark.rutland@arm.com>

Almost all functions in entry-common.c are marked notrace, with
el1_undef and el1_inv being the only exceptions. We appear to have done
this on the assumption that there were no exception registers that we
needed to snapshot, and thus it was safe to run trace code that might
result in further exceptions and clobber those registers.

However, until we inherit the DAIF flags, our irq flag tracing is stale,
and this discrepancy could set off warnings in some configurations.
Given we don't expect to trigger el1_undef or el1_inv unless something
is already wrong, any irqflag warnigns are liable to mask the
information we'd actually care about.

Let's keep things simple and mark el1_undef and el1_inv as notrace.
Developers can trace do_undefinstr and bad_mode if they really want to
monitor these cases.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/entry-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 5dce5e56995a..67198142a0fc 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -36,14 +36,14 @@ static void notrace el1_pc(struct pt_regs *regs, unsigned long esr)
 }
 NOKPROBE_SYMBOL(el1_pc);
 
-static void el1_undef(struct pt_regs *regs)
+static void notrace el1_undef(struct pt_regs *regs)
 {
 	local_daif_inherit(regs);
 	do_undefinstr(regs);
 }
 NOKPROBE_SYMBOL(el1_undef);
 
-static void el1_inv(struct pt_regs *regs, unsigned long esr)
+static void notrace el1_inv(struct pt_regs *regs, unsigned long esr)
 {
 	local_daif_inherit(regs);
 	bad_mode(regs, 0, esr);
-- 
2.11.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-08 18:57 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08 18:56 [PATCH 00/17] arm64: entry deasmification and cleanup Mark Rutland
2020-01-08 18:56 ` Mark Rutland [this message]
2020-01-09  5:21   ` [PATCH 01/17] arm64: entry: mark all entry code as notrace Anshuman Khandual
2020-01-13 15:44     ` Mark Rutland
2020-01-08 18:56 ` [PATCH 02/17] arm64: entry: cleanup el0 svc handler naming Mark Rutland
2020-01-09  5:33   ` Anshuman Khandual
2020-01-08 18:56 ` [PATCH 03/17] arm64: entry: move arm64_preempt_schedule_irq to entry-common.c Mark Rutland
2020-01-09  5:36   ` Anshuman Khandual
2020-01-08 18:56 ` [PATCH 04/17] arm64: entry: move preempt logic to C Mark Rutland
2020-01-09  6:43   ` Anshuman Khandual
2020-01-09 12:22     ` Mark Rutland
2020-01-08 18:56 ` [PATCH 05/17] arm64: entry: add a call_on_stack helper Mark Rutland
2020-01-09  8:00   ` Anshuman Khandual
2020-01-14 18:24     ` Mark Rutland
2020-01-09 14:30   ` Laura Abbott
2020-01-09 14:46     ` Mark Rutland
2020-01-08 18:56 ` [PATCH 06/17] arm64: entry: convert irq entry to C Mark Rutland
2020-01-08 18:56 ` [PATCH 07/17] arm64: entry: convert error " Mark Rutland
2020-01-09  9:12   ` Anshuman Khandual
2020-01-09 12:49     ` Mark Rutland
2020-01-08 18:56 ` [PATCH 08/17] arm64: entry: Split el0_sync_compat from el0_sync Mark Rutland
2020-01-09  9:50   ` Anshuman Khandual
2020-01-08 18:56 ` [PATCH 09/17] arm64: entry: organise handler stubs consistently Mark Rutland
2020-01-09 10:01   ` Anshuman Khandual
2020-01-08 18:56 ` [PATCH 10/17] arm64: entry: consolidate EL1 return paths Mark Rutland
2020-01-10  3:39   ` Anshuman Khandual
2020-01-10 16:02     ` Mark Rutland
2020-01-08 18:56 ` [PATCH 11/17] stackleak: allow C to call stackleak_erase() Mark Rutland
2020-01-10  3:45   ` Anshuman Khandual
2020-01-10 16:07     ` Mark Rutland
2020-01-27 23:00   ` Kees Cook
2020-01-08 18:56 ` [PATCH 12/17] arm64: debug-monitors: refactor MDSCR manipulation Mark Rutland
2020-01-10  4:35   ` Anshuman Khandual
2020-01-10 16:09     ` Mark Rutland
2020-01-08 18:56 ` [PATCH 13/17] arm64: entry: move common el0 entry/return work to C Mark Rutland
2020-01-09 15:19   ` Mark Rutland
2020-01-08 18:56 ` [PATCH 14/17] arm64: entry: move NO_SYSCALL setup " Mark Rutland
2020-01-10  5:37   ` Anshuman Khandual
2020-01-08 18:56 ` [PATCH 15/17] arm64: entry: move ARM64_ERRATUM_845719 workaround " Mark Rutland
2020-01-08 18:56 ` [PATCH 16/17] arm64: entry: move ARM64_ERRATUM_1418040 " Mark Rutland
2020-01-08 18:56 ` [PATCH 17/17] arm64: entry: cleanup sp_el0 manipulation Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200108185634.1163-2-mark.rutland@arm.com \
    --to=mark.rutland@arm.com \
    --cc=alex.popov@linux.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=keescook@chromium.org \
    --cc=labbott@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.