All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Anders Roxell <anders.roxell@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Dave P Martin <dave.martin@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64/alternatives: use subsections for replacement sequences
Date: Thu, 9 Jul 2020 13:43:42 +0100	[thread overview]
Message-ID: <20200709124342.GA28772@willie-the-truck> (raw)
In-Reply-To: <CAMj1kXFg5UN-JvPR3p5PVO015FdRwmDZE46qDvL-QJG-QC-oTg@mail.gmail.com>

On Thu, Jul 09, 2020 at 03:39:53PM +0300, Ard Biesheuvel wrote:
> On Thu, 9 Jul 2020 at 15:31, Ard Biesheuvel <ardb@kernel.org> wrote:
> > It appears that the following code in alternatives.c
> >
> > static bool branch_insn_requires_update(struct alt_instr *alt, unsigned long pc)
> > {
> >     unsigned long replptr;
> >
> >     if (kernel_text_address(pc))
> >        return true;
> >
> > returns true inadvertently for the branch in this piece of code in entry.S
> >
> > alternative_if ARM64_HAS_IRQ_PRIO_MASKING
> >     ldr x20, [sp, #S_PMR_SAVE]
> >     msr_s SYS_ICC_PMR_EL1, x20
> >     mrs_s x21, SYS_ICC_CTLR_EL1
> >     tbz x21, #6, .L__skip_pmr_sync\@ // Check for ICC_CTLR_EL1.PMHE
> >     dsb sy // Ensure priority change is seen by redistributor
> > .L__skip_pmr_sync\@:
> >
> >
> > due to the fact that kernel_text_address() has no way of
> > distinguishing branches inside the subsection from branches that
> > require updating. So the alternatives patching code dutifully updates
> > the tbz opcode and points it to its original target in the subsection.
> >
> > This is going to be rather tricky to fix, unless we special case
> > tbz/cbz branches and other branches with limited range that would
> > never have worked before anyway.
> >
> > For now, better to just revert it and revisit it later.
> >
> 
> ... unless we decide to fix up all branches pointing outside the
> replacement sequence, which is not an entirely unreasonable thing to
> do:
> 
> diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
> index d1757ef1b1e7..7c205f9202a3 100644
> --- a/arch/arm64/kernel/alternative.c
> +++ b/arch/arm64/kernel/alternative.c
> @@ -45,18 +45,11 @@
>  {
>         unsigned long replptr;
> 
> -       if (kernel_text_address(pc))
> -               return true;
> -
>         replptr = (unsigned long)ALT_REPL_PTR(alt);
>         if (pc >= replptr && pc <= (replptr + alt->alt_len))
>                 return false;
> 
> -       /*
> -        * Branching into *another* alternate sequence is doomed, and
> -        * we're not even trying to fix it up.
> -        */
> -       BUG();
> +       return true;

That looks better than the revert to me. Alex -- can you give it a spin with
your setup, please?

Will

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

  reply	other threads:[~2020-07-09 12:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30  8:19 [PATCH] arm64/alternatives: use subsections for replacement sequences Ard Biesheuvel
2020-07-01 17:00 ` Dave P Martin
2020-07-01 17:30   ` Ard Biesheuvel
2020-07-01 17:32     ` Ard Biesheuvel
2020-07-06 15:50       ` Dave Martin
2020-07-06 16:04         ` Ard Biesheuvel
2020-07-07 10:35           ` Dave Martin
2020-07-02 11:56 ` Will Deacon
2020-07-02 13:54 ` Will Deacon
2020-07-09 10:57 ` Alexandru Elisei
2020-07-09 11:12   ` Alexandru Elisei
2020-07-09 12:31     ` Ard Biesheuvel
2020-07-09 12:39       ` Ard Biesheuvel
2020-07-09 12:43         ` Will Deacon [this message]
2020-07-09 12:48         ` Alexandru Elisei

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=20200709124342.GA28772@willie-the-truck \
    --to=will@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=anders.roxell@linaro.org \
    --cc=andre.przywara@arm.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.martin@arm.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \
    /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.