All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] s390/cpacf: Unpoison instruction results
@ 2026-08-07 12:20 Ilya Leoshkevich
  2026-08-07 12:38 ` sashiko-bot
  2026-08-13 14:06 ` Harald Freudenberger
  0 siblings, 2 replies; 6+ messages in thread
From: Ilya Leoshkevich @ 2026-08-07 12:20 UTC (permalink / raw)
  To: Harald Freudenberger, Holger Dengler, Heiko Carstens,
	Vasily Gorbik, Alexander Gordeev
  Cc: linux-s390, linux-kernel, Ilya Leoshkevich

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).

 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);
 }
 
 #endif	/* _ASM_S390_CPACF_H */
-- 
2.55.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] s390/cpacf: Unpoison instruction results
  2026-08-07 12:20 [PATCH v2] s390/cpacf: Unpoison instruction results Ilya Leoshkevich
@ 2026-08-07 12:38 ` sashiko-bot
  2026-08-07 13:07   ` Ilya Leoshkevich
  2026-08-13 14:06 ` Harald Freudenberger
  1 sibling, 1 reply; 6+ messages in thread
From: sashiko-bot @ 2026-08-07 12:38 UTC (permalink / raw)
  To: Ilya Leoshkevich
  Cc: Vasily Gorbik, Alexander Gordeev, linux-s390, Heiko Carstens

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] `__cpacf_qai` unpoisons the entire 256-byte `cpacf_qai_t` structure, which could mask kernel stack leaks if a specific instruction's QAI output is smaller than 256 bytes.
--

--- Patch [1]: [PATCH v2] s390/cpacf: Unpoison instruction results ---
commit 587dbefd826fa4c40d5401b72be74dfb37147586
Author: Ilya Leoshkevich <iii@linux.ibm.com>

s390/cpacf: Unpoison instruction results

This commit explicitly unpoisons CPACF instruction outputs to stop KMSAN from
reporting them as uninitialized. It leaves variable-length parameter blocks
for the callers to handle.

Link: https://lore.kernel.org/linux-s390/20260806190223.3292580-1-iii@linux.ibm.com/

> 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

[ ... ]

> @@ -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));

[Severity: Medium]
Will unconditionally unpoisoning the entire 256-byte cpacf_qai_t structure
potentially mask kernel stack leaks from KMSAN?

If a specific instruction's QAI output is smaller than 256 bytes, this
unpoison would hide the remaining uninitialized stack bytes. In
arch/s390/kernel/cpacf.c, the uninitialized stack structure is copied
directly to userspace:

arch/s390/kernel/cpacf.c:name##_query_auth_info_raw_read() {
    ...
    cpacf_qai_t qai;
    ...
    if (!cpacf_qai(CPACF_##instruction, &qai))
        return -EOPNOTSUPP;
    return memory_read_from_buffer(buf, count, &offs, &qai,
                                   sizeof(qai));
}

Could this regression lead to uninitialized stack bytes leaking to userspace
via the sysfs attribute without KMSAN detecting it, if any current or future
hardware query instructions write less than the full struct size?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807122132.3592583-1-iii@linux.ibm.com?part=1

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] s390/cpacf: Unpoison instruction results
  2026-08-07 12:38 ` sashiko-bot
@ 2026-08-07 13:07   ` Ilya Leoshkevich
  0 siblings, 0 replies; 6+ messages in thread
From: Ilya Leoshkevich @ 2026-08-07 13:07 UTC (permalink / raw)
  To: sashiko-reviews
  Cc: Vasily Gorbik, Alexander Gordeev, linux-s390, Heiko Carstens



On 8/7/26 14:38, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] `__cpacf_qai` unpoisons the entire 256-byte `cpacf_qai_t` structure, which could mask kernel stack leaks if a specific instruction's QAI output is smaller than 256 bytes.
> --
> 
> --- Patch [1]: [PATCH v2] s390/cpacf: Unpoison instruction results ---
> commit 587dbefd826fa4c40d5401b72be74dfb37147586
> Author: Ilya Leoshkevich <iii@linux.ibm.com>
> 
> s390/cpacf: Unpoison instruction results
> 
> This commit explicitly unpoisons CPACF instruction outputs to stop KMSAN from
> reporting them as uninitialized. It leaves variable-length parameter blocks
> for the callers to handle.
> 
> Link: https://lore.kernel.org/linux-s390/20260806190223.3292580-1-iii@linux.ibm.com/
> 
>> 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
> 
> [ ... ]
> 
>> @@ -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));
> 
> [Severity: Medium]
> Will unconditionally unpoisoning the entire 256-byte cpacf_qai_t structure
> potentially mask kernel stack leaks from KMSAN?
> 
> If a specific instruction's QAI output is smaller than 256 bytes, this
> unpoison would hide the remaining uninitialized stack bytes. In
> arch/s390/kernel/cpacf.c, the uninitialized stack structure is copied
> directly to userspace:
> 
> arch/s390/kernel/cpacf.c:name##_query_auth_info_raw_read() {
>      ...
>      cpacf_qai_t qai;
>      ...
>      if (!cpacf_qai(CPACF_##instruction, &qai))
>          return -EOPNOTSUPP;
>      return memory_read_from_buffer(buf, count, &offs, &qai,
>                                     sizeof(qai));
> }
> 
> Could this regression lead to uninitialized stack bytes leaking to userspace
> via the sysfs attribute without KMSAN detecting it, if any current or future
> hardware query instructions write less than the full struct size?
> 
>>   }

POp documents that code 127 (Query-Authentication-Information) format 0
(and there are no other formats at the moment) blocks are always 256
bytes and all of these bytes are stored. Reserved bytes are stored as 0.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] s390/cpacf: Unpoison instruction results
  2026-08-07 12:20 [PATCH v2] s390/cpacf: Unpoison instruction results Ilya Leoshkevich
  2026-08-07 12:38 ` sashiko-bot
@ 2026-08-13 14:06 ` Harald Freudenberger
  2026-08-13 14:09   ` Ilya Leoshkevich
  1 sibling, 1 reply; 6+ messages in thread
From: Harald Freudenberger @ 2026-08-13 14:06 UTC (permalink / raw)
  To: Ilya Leoshkevich
  Cc: Holger Dengler, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
	linux-s390, linux-kernel

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 */

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] s390/cpacf: Unpoison instruction results
  2026-08-13 14:06 ` Harald Freudenberger
@ 2026-08-13 14:09   ` Ilya Leoshkevich
  2026-08-13 15:51     ` Harald Freudenberger
  0 siblings, 1 reply; 6+ messages in thread
From: Ilya Leoshkevich @ 2026-08-13 14:09 UTC (permalink / raw)
  To: freude
  Cc: Holger Dengler, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
	linux-s390, linux-kernel



On 8/13/26 16:06, Harald Freudenberger wrote:
> 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.

Will do, thanks!

May I ask you to add a proper KMSAN annotation while fixing CC1/CC2
cases? Alternatively I can do it myself afterwards, of course.

> 
>>  }
>>
>>  #endif    /* _ASM_S390_CPACF_H */


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] s390/cpacf: Unpoison instruction results
  2026-08-13 14:09   ` Ilya Leoshkevich
@ 2026-08-13 15:51     ` Harald Freudenberger
  0 siblings, 0 replies; 6+ messages in thread
From: Harald Freudenberger @ 2026-08-13 15:51 UTC (permalink / raw)
  To: Ilya Leoshkevich
  Cc: Holger Dengler, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
	linux-s390, linux-kernel

On 2026-08-13 16:09, Ilya Leoshkevich wrote:
> On 8/13/26 16:06, Harald Freudenberger wrote:
>> 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.
> 
> Will do, thanks!
> 
> May I ask you to add a proper KMSAN annotation while fixing CC1/CC2
> cases? Alternatively I can do it myself afterwards, of course.
> 

Yes, I'll do that.

>> 
>>>  }
>>> 
>>>  #endif    /* _ASM_S390_CPACF_H */

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-08-13 15:51 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-07 12:20 [PATCH v2] s390/cpacf: Unpoison instruction results Ilya Leoshkevich
2026-08-07 12:38 ` sashiko-bot
2026-08-07 13:07   ` Ilya Leoshkevich
2026-08-13 14:06 ` Harald Freudenberger
2026-08-13 14:09   ` Ilya Leoshkevich
2026-08-13 15:51     ` Harald Freudenberger

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.