All of lore.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>,
	leo.bras@arm.com, leo.yan@arm.com,
	 linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, palmer@dabbelt.com,
	 paulmck@kernel.org, puranjay@kernel.org, usama.arif@linux.dev,
	kernel-team@meta.com
Subject: Re: [PATCH RFC] arm64/irqflags: force inline of arch_local_irq_enable()
Date: Mon, 20 Apr 2026 06:15:24 -0700	[thread overview]
Message-ID: <aeYmHr_lgPJbBoL_@gmail.com> (raw)
In-Reply-To: <aeYkz_4WKDdb1NTp@J2N7QTR9R3>

On Mon, Apr 20, 2026 at 02:06:23PM +0100, Mark Rutland wrote:
> On Mon, Apr 20, 2026 at 05:42:11AM -0700, Breno Leitao wrote:
> > arch_local_irq_enable() is a small wrapper that dispatches between two
> > unmask paths: __daif_local_irq_enable() on most systems, and
> > __pmr_local_irq_enable() on builds that use GIC PMR-based masking
> > (Pseudo-NMI). Both leaf primitives are already __always_inline; the
> > wrapper itself is plain "static inline".
> >
> > In practice the compiler does not always inline the wrapper.
>
> I think this was my mistake, and we should have marked all the helpers
> as __always_inline for noinstr safety, as x86 did in commit:
>
>   7a745be1cc90 ("x86/entry: __always_inline irqflags for noinstr")
>
> I think we should mark all of the following as __always_inline in one
> go:
>
> * arch_local_irq_enable()
> * arch_local_irq_disable()
> * arch_local_save_flags()
> * arch_irqs_disabled_flags()
> * arch_irqs_disabled()
> * arch_local_irq_save()
> * arch_local_irq_restore()
>
> ... which then ensures noinstr safety, and has the side benefit of
> giving nicer traces as you're suggesting here.
>
> Are you happy to try that?

Absolutely, I'll work on testing it that and put together a patch
addressing all of them.

Should this be targeted for stable backports as well? If so, which
commit should I reference in the Fixes tag?

Thanks for the quick answer,
--breno


  reply	other threads:[~2026-04-20 13:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20 12:42 [PATCH RFC] arm64/irqflags: force inline of arch_local_irq_enable() Breno Leitao
2026-04-20 13:06 ` Mark Rutland
2026-04-20 13:15   ` Breno Leitao [this message]
2026-04-20 14:14     ` Mark Rutland
2026-04-20 14:37       ` Breno Leitao

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=aeYmHr_lgPJbBoL_@gmail.com \
    --to=leitao@debian.org \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@meta.com \
    --cc=leo.bras@arm.com \
    --cc=leo.yan@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=palmer@dabbelt.com \
    --cc=paulmck@kernel.org \
    --cc=puranjay@kernel.org \
    --cc=usama.arif@linux.dev \
    --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.