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

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

On 2026-10-06 15:39, Heiko Carstens wrote:
> On Tue, Oct 06, 2026 at 03:29:28PM +0200, Harald Freudenberger wrote:
>> 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.
> 
> That should have been "...it would make sense to..."
> 
>> I have no idea what you mean here...
> 
> See include/linux/instrumented.h - you can the kernel about
> memory accesses also kasan and kcsan. Your patch only adds
> that for kmsan. See arch/s390/include/asm/fpu-insn.h for many
> examples. I'm aware that such annotations are currently missing
> for many of our inline asms. But since you are at it.
> 
> Up to you if you want to add it or not. Just a suggestion.
> 

Ok thanks. But I would prefer to have this seperate from this kma 
rework.
It would make sense to have that notations then for all the inline 
functions
in cpacf.h.

>> > 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.
> 
> It would be helpful if you would add information like that in the
> cover-letter. This saves both of us a bit of time.

Ok - will do. I avoided to have direct address people in the cover 
letter.
But when you are ok with that, let's run it that way next time.