From: Harald Freudenberger <freude@linux.ibm.com>
To: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Holger Dengler <dengler@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] s390/cpacf: Unpoison instruction results
Date: Thu, 13 Aug 2026 16:06:44 +0200 [thread overview]
Message-ID: <6a2841287fe60bf310d302b6f4293329@linux.ibm.com> (raw)
In-Reply-To: <20260807122132.3592583-1-iii@linux.ibm.com>
On 2026-08-07 14:20, Ilya Leoshkevich wrote:
> Stop KMSAN from complaining about CPACF outputs being uninitialized.
>
> Do not unpoison variable-length parameter blocks: mapping function
> codes (like CPACF_KIMD_SHA_256) to lengths is ugly. Let the callers
> handle this once need arises.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
> v1:
> https://lore.kernel.org/linux-s390/20260806190223.3292580-1-iii@linux.ibm.com/
> v1 -> v2: Unpoison outputs of more instructions (Sashiko).
>
See my comment below.
> arch/s390/include/asm/cpacf.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/s390/include/asm/cpacf.h
> b/arch/s390/include/asm/cpacf.h
> index a83683169d98d..13d6a6344802a 100644
> --- a/arch/s390/include/asm/cpacf.h
> +++ b/arch/s390/include/asm/cpacf.h
> @@ -301,6 +301,7 @@ static __always_inline void __cpacf_query(unsigned
> int opcode,
> cpacf_mask_t *mask)
> {
> __cpacf_query_insn(opcode, mask, CPACF_FC_QUERY);
> + kmsan_unpoison_memory(mask, sizeof(*mask));
> }
>
> static __always_inline int __cpacf_check_opcode(unsigned int opcode)
> @@ -370,6 +371,7 @@ static __always_inline int
> cpacf_query_func(unsigned int opcode,
> static __always_inline void __cpacf_qai(unsigned int opcode,
> cpacf_qai_t *qai)
> {
> __cpacf_query_insn(opcode, qai, CPACF_FC_QUERY_AUTH_INFO);
> + kmsan_unpoison_memory(qai, sizeof(*qai));
> }
>
> /**
> @@ -422,6 +424,7 @@ static inline int cpacf_km(unsigned long func, void
> *param,
> [opc] "i" (CPACF_KM)
> : "cc", "memory", "0", "1");
>
> + kmsan_unpoison_memory(dest, src_len - s.odd);
> return src_len - s.odd;
> }
>
> @@ -454,6 +457,7 @@ static inline int cpacf_kmc(unsigned long func,
> void *param,
> [opc] "i" (CPACF_KMC)
> : "cc", "memory", "0", "1");
>
> + kmsan_unpoison_memory(dest, src_len - s.odd);
> return src_len - s.odd;
> }
>
> @@ -587,6 +591,7 @@ static inline int cpacf_kmctr(unsigned long func,
> void *param, u8 *dest,
> [opc] "i" (CPACF_KMCTR)
> : "cc", "memory", "0", "1");
>
> + kmsan_unpoison_memory(dest, src_len - s.odd);
> return src_len - s.odd;
> }
>
> @@ -619,6 +624,7 @@ static inline void cpacf_prno(unsigned long func,
> void *param,
> : [fc] "d" (func), [pba] "d" ((unsigned long)param),
> [seed] "d" (s.pair), [opc] "i" (CPACF_PRNO)
> : "cc", "memory", "0", "1");
> + kmsan_unpoison_memory(dest, dest_len);
> }
>
> /**
> @@ -731,6 +737,7 @@ static inline void cpacf_kma(unsigned long func,
> void *param, u8 *dest,
> : [fc] "d" (func), [pba] "d" ((unsigned long)param),
> [opc] "i" (CPACF_KMA)
> : "cc", "memory", "0", "1");
> + kmsan_unpoison_memory(dest, src_len);
I am unhappy with this kma thing. This would only work properly with
CC 0. But CC 1 and 2 are not handled properly. However, I had a closer
look onto the AR for kma and ... well this inline function should
handle CC 1 and CC 2 somehow and it should similar to the other inline
functions return the number of bytes processed like for example
cpacf_km().
I'll open up a bugzilla to fix this kma inline function.
If you leave out this kma hunk you can add my R-b.
> }
>
> #endif /* _ASM_S390_CPACF_H */
next prev parent reply other threads:[~2026-08-13 14:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 12:20 [PATCH v2] s390/cpacf: Unpoison instruction results Ilya Leoshkevich
2026-08-13 14:06 ` Harald Freudenberger [this message]
2026-08-13 14:09 ` Ilya Leoshkevich
2026-08-13 15:51 ` Harald Freudenberger
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=6a2841287fe60bf310d302b6f4293329@linux.ibm.com \
--to=freude@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=dengler@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@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