From: Heiko Carstens <hca@linux.ibm.com>
To: Sasha Levin <sashal@kernel.org>
Cc: stable@vger.kernel.org, Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Subject: Re: [PATCH 6.12.y 3/3] s390/mm: Fix __ptep_rdp() inline assembly
Date: Tue, 25 Nov 2025 11:41:48 +0100 [thread overview]
Message-ID: <20251125104148.10410E98-hca@linux.ibm.com> (raw)
In-Reply-To: <20251124171719.4158053-3-sashal@kernel.org>
On Mon, Nov 24, 2025 at 12:17:19PM -0500, Sasha Levin wrote:
> From: Heiko Carstens <hca@linux.ibm.com>
>
> [ Upstream commit 31475b88110c4725b4f9a79c3a0d9bbf97e69e1c ]
>
> When a zero ASCE is passed to the __ptep_rdp() inline assembly, the
> generated instruction should have the R3 field of the instruction set to
> zero. However the inline assembly is written incorrectly: for such cases a
> zero is loaded into a register allocated by the compiler and this register
> is then used by the instruction.
>
> This means that selected TLB entries may not be flushed since the specified
> ASCE does not match the one which was used when the selected TLB entries
> were created.
>
> Fix this by removing the asce and opt parameters of __ptep_rdp(), since
> all callers always pass zero, and use a hard-coded register zero for
> the R3 field.
>
> Fixes: 0807b856521f ("s390/mm: add support for RDP (Reset DAT-Protection)")
> Cc: stable@vger.kernel.org
> Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> arch/s390/include/asm/pgtable.h | 12 +++++-------
> arch/s390/mm/pgtable.c | 4 ++--
> 2 files changed, 7 insertions(+), 9 deletions(-)
...
> @@ -1304,7 +1302,7 @@ static inline void flush_tlb_fix_spurious_fault(struct vm_area_struct *vma,
> * A local RDP can be used to do the flush.
> */
> if (cpu_has_rdp() && !(pte_val(*ptep) & _PAGE_PROTECT))
> - __ptep_rdp(address, ptep, 0, 0, 1);
> + __ptep_rdp(address, ptep, 1);
> }
I don't think it makes too much sense to backport only two of the many
cpu_has_xxx() conversion patches just to avoid the minimal difference
in context for this patch. From my point of view this puts the stable
branch into an inconsistent state wrt s390 and cpu features - old and
new interfaces are mixed.
I will provide a different stable backport patch which addresses only
the context diff. Then you can decide.
next prev parent reply other threads:[~2025-11-25 10:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-24 13:22 FAILED: patch "[PATCH] s390/mm: Fix __ptep_rdp() inline assembly" failed to apply to 6.12-stable tree gregkh
2025-11-24 17:17 ` [PATCH 6.12.y 1/3] s390/cpufeature: Convert MACHINE_HAS_SEQ_INSN to cpu_has_seq_insn() Sasha Levin
2025-11-24 17:17 ` [PATCH 6.12.y 2/3] s390/cpufeature: Convert MACHINE_HAS_RDP to cpu_has_rdp() Sasha Levin
2025-11-24 17:17 ` [PATCH 6.12.y 3/3] s390/mm: Fix __ptep_rdp() inline assembly Sasha Levin
2025-11-25 10:41 ` Heiko Carstens [this message]
2025-11-25 10:46 ` [PATCH 6.12.y] " Heiko Carstens
2025-11-26 12:11 ` Sasha Levin
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=20251125104148.10410E98-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=sashal@kernel.org \
--cc=stable@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).