mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Heiko Carstens <hca@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v2 10/10] s390/maccess: Remove spinlock from __s390_kernel_write()
Date: Wed, 28 Oct 2026 21:59:46 +0100	[thread overview]
Message-ID: <11f7072d-3c4b-4ed5-9954-49c39a012d8b@linux.ibm.com> (raw)
In-Reply-To: <20261027143030.3154657-11-hca@linux.ibm.com>



On 10/27/26 15:30, Heiko Carstens wrote:
> The spinlock in __s390_kernel_write() was introduced to serialize the
> read-modify-write sequence against concurrent callers. Now that all
> runtime callers of s390_kernel_write() hold the text_mutex, the
> spinlock is not required anymore.
> 
> Replace it with preempt_disable() / preempt_enable() and sync_core().
> Previously, CPU serialization was implicitly done by other
> instructions. Make this explicit with sync_core() instead of
> relying on that.
> 
> Preemption is disabled so that sync_core() issues the CPU serialization
> instruction on the same CPU that executed the stores. This completes all
> previous stores and makes them visible to other CPUs.

Doesn't preemption happen only via interrupts, which always serialize?
> Other CPUs need to perform CPU serialization, e.g. with text_poke_sync(),
> to discard already prefetched instructions.
> 
> To verify that text_mutex is held instead of the spinlock, add a
> lockdep_assert_held() call to s390_kernel_write(). To make that work
> a change to the kprobes code is required:
> 
> swap_instruction(), which calls s390_kernel_write(), may be called in
> stop_machine() context.
> For that case the task which calls s390_kernel_write() is not the task
> which called stop_machine() - lockdep_assert_held() will report that
> text_mutex is not held by the current task, even though text_mutex is
> held by the stop_machine() caller. Exclusive text write access is
> guaranteed.
> Work around that by calling the non-checking __s390_kernel_write(),
> and add lockdep_assert_held() checks to arch_arm_kprobe() and
> arch_disarm_kprobe().
> 
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
>   arch/s390/include/asm/text-patching.h | 7 +++++--
>   arch/s390/kernel/kprobes.c            | 4 +++-
>   arch/s390/mm/maccess.c                | 8 +++-----
>   3 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/s390/include/asm/text-patching.h b/arch/s390/include/asm/text-patching.h
> index c2f87f20ff97..a382a3e7c2f8 100644
> --- a/arch/s390/include/asm/text-patching.h
> +++ b/arch/s390/include/asm/text-patching.h
> @@ -19,9 +19,12 @@ void *__s390_kernel_write(void *dst, const void *src, size_t size);
>   
>   static inline void *s390_kernel_write(void *dst, const void *src, size_t size)
>   {
> -	if (__is_defined(__DECOMPRESSOR))
> -		return memcpy(dst, src, size);
> +#ifdef __DECOMPRESSOR
> +	return memcpy(dst, src, size);
> +#else
> +	lockdep_assert_held(&text_mutex);
>   	return __s390_kernel_write(dst, src, size);
> +#endif
>   }

I assume #ifdef is required because lockdep_assert_held() is not
available in decompressor and there are no stubs?


Anyhow:

Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>

[...]

      reply	other threads:[~2026-10-28 20:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 14:30 [PATCH v2 00/10] s390: Consistent usage of text_mutex Heiko Carstens
2026-10-27 14:30 ` [PATCH v2 01/10] s390/jump_label: Serialize text patching with text_mutex Heiko Carstens
2026-10-28 10:50   ` Ilya Leoshkevich
2026-10-27 14:30 ` [PATCH v2 02/10] s390/ftrace: " Heiko Carstens
2026-10-28 10:54   ` Ilya Leoshkevich
2026-10-27 14:30 ` [PATCH v2 03/10] s390/bpf: " Heiko Carstens
2026-10-28 10:56   ` Ilya Leoshkevich
2026-10-27 14:30 ` [PATCH v2 04/10] s390/runtime-const: " Heiko Carstens
2026-10-28 10:58   ` Ilya Leoshkevich
2026-10-28 11:09     ` Heiko Carstens
2026-10-28 12:22       ` Ilya Leoshkevich
2026-10-28 13:43         ` Heiko Carstens
2026-10-27 14:30 ` [PATCH v2 05/10] s390/module: " Heiko Carstens
2026-10-28 10:59   ` Ilya Leoshkevich
2026-10-27 14:30 ` [PATCH v2 06/10] s390/stackprotector: " Heiko Carstens
2026-10-28 12:23   ` Ilya Leoshkevich
2026-10-27 14:30 ` [PATCH v2 07/10] s390/nospec-branch: " Heiko Carstens
2026-10-28 12:24   ` Ilya Leoshkevich
2026-10-27 14:30 ` [PATCH v2 08/10] s390/alternative: " Heiko Carstens
2026-10-28 12:25   ` Ilya Leoshkevich
2026-10-27 14:30 ` [PATCH v2 09/10] s390/uaccess: Move s390_kernel_write() to asm/text-patching.h Heiko Carstens
2026-10-28 12:26   ` Ilya Leoshkevich
2026-10-27 14:30 ` [PATCH v2 10/10] s390/maccess: Remove spinlock from __s390_kernel_write() Heiko Carstens
2026-10-28 20:59   ` Ilya Leoshkevich [this message]

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=11f7072d-3c4b-4ed5-9954-49c39a012d8b@linux.ibm.com \
    --to=iii@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=svens@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®