All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Mark Brown <broonie@kernel.org>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	 "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
	Marc Zyngier <maz@kernel.org>,
	 Suzuki K Poulose <suzuki.poulose@arm.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH 0/6] arm64: boot cleanups
Date: Thu, 20 May 2021 16:46:46 +0200	[thread overview]
Message-ID: <CAMj1kXF7mHsq=bvM0zubAGhJ3cL7VwTg+49wi+X5W=CitXmaEQ@mail.gmail.com> (raw)
In-Reply-To: <20210520115031.18509-1-mark.rutland@arm.com>

On Thu, 20 May 2021 at 13:50, Mark Rutland <mark.rutland@arm.com> wrote:
>
> This series (based on v5.13-rc1) reworks the way we initialize some state at
> boot time, simplifying and unifying the logic for primary and secondary CPUs.
> This allows us to initalize the per-cpu offsets earlier (which will help to
> enable KCSAN), and reduces the data we need to pass to a secondary. In future,
> this should allow us to transfer the secondary data atomically and make the
> secondary boot paths more robust to arbitrarily long delays.
>
> I've based this on Mahdavan's stacktrace termination patch [1] (duplicated here
> unchanged), since it made sense to combine the unwind initialization along with
> the other CPU state, and otherwise there would be non-trivial merge conflicts.
>
> I've given the series some boot testing with a variety of configurations,
> checking that stacktraces work correctly, etc.
>
> The series can be found on my arm64/boot/rework branch on kernel.org:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/boot/rework
>   git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/boot/rework
>
> Thanks,
> Mark.
>
> [1] https://lore.kernel.org/r/20210510110026.18061-1-mark.rutland@arm.com
>
> Madhavan T. Venkataraman (1):
>   arm64: Implement stack trace termination record
>
> Mark Rutland (5):
>   arm64: assembler: add set_this_cpu_offset
>   arm64: smp: remove pointless secondary_data maintenance
>   arm64: smp: remove stack from secondary_data
>   arm64: smp: unify task and sp setup
>   arm64: smp: initialize cpu offset earlier
>

For the series

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

Note that this will conflict with Fuad's cache maintenance cleanup series.


>  arch/arm64/include/asm/assembler.h | 18 ++++++++----
>  arch/arm64/include/asm/smp.h       |  2 --
>  arch/arm64/kernel/asm-offsets.c    |  2 +-
>  arch/arm64/kernel/entry.S          |  2 +-
>  arch/arm64/kernel/head.S           | 58 ++++++++++++++++++++++++--------------
>  arch/arm64/kernel/process.c        |  5 ++++
>  arch/arm64/kernel/setup.c          |  6 ----
>  arch/arm64/kernel/smp.c            | 14 ++++-----
>  arch/arm64/kernel/stacktrace.c     | 16 +++++------
>  arch/arm64/mm/proc.S               | 12 ++------
>  10 files changed, 72 insertions(+), 63 deletions(-)
>
> --
> 2.11.0
>

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

  parent reply	other threads:[~2021-05-20 14:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 11:50 [PATCH 0/6] arm64: boot cleanups Mark Rutland
2021-05-20 11:50 ` [PATCH 1/6] arm64: Implement stack trace termination record Mark Rutland
2021-05-20 11:50 ` [PATCH 2/6] arm64: assembler: add set_this_cpu_offset Mark Rutland
2021-05-20 11:50 ` [PATCH 3/6] arm64: smp: remove pointless secondary_data maintenance Mark Rutland
2021-05-20 11:50 ` [PATCH 4/6] arm64: smp: remove stack from secondary_data Mark Rutland
2021-05-20 11:50 ` [PATCH 5/6] arm64: smp: unify task and sp setup Mark Rutland
2021-05-20 11:50 ` [PATCH 6/6] arm64: smp: initialize cpu offset earlier Mark Rutland
2021-05-20 14:46 ` Ard Biesheuvel [this message]
2021-05-26 22:16 ` [PATCH 0/6] arm64: boot cleanups Will Deacon
2021-05-27  9:33   ` 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='CAMj1kXF7mHsq=bvM0zubAGhJ3cL7VwTg+49wi+X5W=CitXmaEQ@mail.gmail.com' \
    --to=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=madvenka@linux.microsoft.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@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.