Re: [PATCH v1 1/2] s390/cpacf: Rework cpacf_kma() to return condition code

[Harald Freudenberger <freude@linux.ibm.com>]

On 2026-10-06 10:30, Heiko Carstens wrote:
> On Mon, Oct 05, 2026 at 04:14:15PM +0200, Harald Freudenberger wrote:
> ...
>> better readability. Additionally add an kmsan_unpoison_memory()
>> statement to reflect the updated memory by hardware.
> ...
>> @@ -731,12 +739,16 @@ static inline void cpacf_kma(unsigned long func, 
>> void *param, u8 *dest,
>>  		"	lgr	0,%[fc]\n"
>>  		"	lgr	1,%[pba]\n"
>>  		"0:	.insn	rrf,%[opc] << 16,%[dst],%[src],%[aad],0\n"
>> -		"	brc	1,0b"	/* handle partial completion */
>> -		: [dst] "+&d" (d.pair), [src] "+&d" (s.pair),
>> +		"	brc	1,0b\n"	/* handle partial completion */
>> +		CC_IPM(cc)
>> +		: CC_OUT(cc, cc), [dst] "+&d" (d.pair), [src] "+&d" (s.pair),
>>  		  [aad] "+&d" (a.pair)
>>  		: [fc] "d" (func), [pba] "d" ((unsigned long)param),
>>  		  [opc] "i" (CPACF_KMA)
>> -		: "cc", "memory", "0", "1");
>> +		: CC_CLOBBER_LIST("memory", "0", "1"));
>> +
>> +	kmsan_unpoison_memory(dest, src_len - s.odd);
> 
> Since you added explicit instrumentation here it would sense so add
> kasan/kcsan instrumentation by adding an instrument_write() call.

I have no idea what you mean here...

> 
> Also, given that this is in-kernel crypto, shouldn't this series go
> via the crypto tree?

Well, this is to be negotiated. I first wanted to collect an RB 
statement.
For cpacf.h I see this in the s390 realm but the 2nd patch is clearly
in-kernel crypto. So I would have asked Herbert to have this processed
via s390 subsystem as the important changes are in cpacf.h. However,
let's first solve your "instrument_write()" call.
I was just following the other kmsan_unpoison_memory() statements
which recently were added by Ilya. I do not see any instrument_write()
in the whole cpacf.h.