All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	linux-mips@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 3/3] jump_label: make initial NOP patching the special case
Date: Wed, 15 Jun 2022 10:52:41 +0100	[thread overview]
Message-ID: <Yqmr6fvu4OYkarCm@FVFF77S0Q05N> (raw)
In-Reply-To: <20220608104512.1176209-4-ardb@kernel.org>

On Wed, Jun 08, 2022 at 12:45:12PM +0200, Ard Biesheuvel wrote:
> Instead of defaulting to patching NOP opcodes at init time, and leaving
> it to the architectures to override this if this is not needed, switch
> to a model where doing nothing is the default. This is the common case
> by far, as only MIPS requires NOP patching at init time. On all other
> architectures, the correct encodings are emitted by the compiler and so
> no initial patching is needed.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  Documentation/staging/static-keys.rst |  3 ---
>  arch/arc/kernel/jump_label.c          | 13 -------------
>  arch/arm/kernel/jump_label.c          |  6 ------
>  arch/arm64/kernel/jump_label.c        | 11 -----------
>  arch/mips/include/asm/jump_label.h    |  2 ++
>  arch/parisc/kernel/jump_label.c       | 11 -----------
>  arch/riscv/kernel/jump_label.c        | 12 ------------
>  arch/s390/kernel/jump_label.c         |  5 -----
>  arch/x86/kernel/jump_label.c          | 13 -------------
>  kernel/jump_label.c                   | 14 +++-----------
>  10 files changed, 5 insertions(+), 85 deletions(-)

I have one minor comment below, but either way this is a nice cleanup (and I'm
always happy to see __weak functions disappear), so FWIW:

  Acked-by: Mark Rutland <mark.rutland@arm.com>

[...]

> diff --git a/kernel/jump_label.c b/kernel/jump_label.c
> index b1ac2948be79..ff8576c00893 100644
> --- a/kernel/jump_label.c
> +++ b/kernel/jump_label.c
> @@ -332,17 +332,9 @@ static int __jump_label_text_reserved(struct jump_entry *iter_start,
>  	return 0;
>  }
>  
> -/*
> - * Update code which is definitely not currently executing.
> - * Architectures which need heavyweight synchronization to modify
> - * running code can override this to make the non-live update case
> - * cheaper.
> - */
> -void __weak __init_or_module arch_jump_label_transform_static(struct jump_entry *entry,
> -					    enum jump_label_type type)
> -{
> -	arch_jump_label_transform(entry, type);
> -}
> +#ifndef arch_jump_label_transform_static
> +#define arch_jump_label_transform_static(entry, type)
> +#endif

It might be slightly better to make this a static inline stub so that we always
get the compiler to type-check it, e.g.

| #ifndef arch_jump_label_transform_static
| static inline void arch_jump_label_transform_static(struct jump_entry *entry,
| 						    enum jump_label_type type)
| {
| 	/* nothing to do on most architectures */
| }
| #define arch_jump_label_transform_static arch_jump_label_transform_static
| #endif

Mark.

  reply	other threads:[~2022-06-15  9:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 10:45 [PATCH 0/3] jump_label: get rid of NOP patching where possible Ard Biesheuvel
2022-06-08 10:45 ` [PATCH 1/3] jump_label: s390: avoid pointless initial NOP patching Ard Biesheuvel
2022-06-08 10:45 ` [PATCH 2/3] jump_label: mips: move module NOP patching into arch code Ard Biesheuvel
2022-06-10  0:42   ` kernel test robot
2022-06-08 10:45 ` [PATCH 3/3] jump_label: make initial NOP patching the special case Ard Biesheuvel
2022-06-15  9:52   ` Mark Rutland [this message]
2022-06-15  9:58     ` Ard Biesheuvel
2022-06-15 10:06     ` Peter Zijlstra
2022-06-15 10:20       ` Ard Biesheuvel

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=Yqmr6fvu4OYkarCm@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=ardb@kernel.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=svens@linux.ibm.com \
    --cc=tsbogend@alpha.franken.de \
    /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.