All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Janosch Frank <frankja@linux.ibm.com>, KVM <kvm@vger.kernel.org>,
	David Hildenbrand <david@kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>
Subject: Re: [PATCH 1/1] KVM: s390: Fix memory corruption by not reinjecting CK machine checks
Date: Thu, 6 Aug 2026 16:39:26 +0200	[thread overview]
Message-ID: <d32c5862-1e64-496c-bf03-5928c2ea1dfd@linux.ibm.com> (raw)
In-Reply-To: <20260806163739.7b1ee8fd@p-imbrenda>



Am 06.08.26 um 16:37 schrieb Claudio Imbrenda:
> On Thu,  6 Aug 2026 14:52:41 +0200
> Christian Borntraeger <borntraeger@linux.ibm.com> wrote:
> 
>> Channel-subsystem damage machine checks are for the host channel
>> subsystem. The guest channel subsystem is emulated in the userspace VMM.
>> There is no point in forwarding such machine checks into the guest.
>>
>> This also simplifies the machine check reinjection and avoids kfree of a
>> stack variable as reported by sashiko.  There might be still machine
>> checks that have the ck bit set with another bit (like instruction
>> damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and
>> ED bits already are.
>>
>> Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
>> ---
>>   arch/s390/include/asm/nmi.h |  1 +
>>   arch/s390/kernel/nmi.c      |  4 ++--
>>   arch/s390/kvm/interrupt.c   | 24 ++++++++----------------
>>   3 files changed, 11 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/s390/include/asm/nmi.h b/arch/s390/include/asm/nmi.h
>> index 6454c1531854..dd26c20bd231 100644
>> --- a/arch/s390/include/asm/nmi.h
>> +++ b/arch/s390/include/asm/nmi.h
>> @@ -22,6 +22,7 @@
>>   #define MCCK_CODE_SYSTEM_DAMAGE		BIT(63)
>>   #define MCCK_CODE_EXT_DAMAGE		BIT(63 - 5)
>>   #define MCCK_CODE_CP			BIT(63 - 9)
>> +#define MCCK_CODE_CK			BIT(63 - 11)
>>   #define MCCK_CODE_STG_ERROR		BIT(63 - 16)
>>   #define MCCK_CODE_STG_KEY_ERROR		BIT(63 - 18)
>>   #define MCCK_CODE_STG_DEGRAD		BIT(63 - 19)
>> diff --git a/arch/s390/kernel/nmi.c b/arch/s390/kernel/nmi.c
>> index e17a59d4d5a4..652b98795243 100644
>> --- a/arch/s390/kernel/nmi.c
>> +++ b/arch/s390/kernel/nmi.c
>> @@ -345,7 +345,7 @@ static void notrace s390_backup_mcck_info(struct pt_regs *regs)
>>   	sie_page = container_of(sie_block, struct sie_page, sie_block);
>>   	mcck_backup = &sie_page->mcck_info;
>>   	mcck_backup->mcic = get_lowcore()->mcck_interruption_code &
>> -				~(MCCK_CODE_CP | MCCK_CODE_EXT_DAMAGE);
>> +			~(MCCK_CODE_CP | MCCK_CODE_EXT_DAMAGE | MCCK_CODE_CK);
> 
> ... here, instead of duplicating it?
> 
>>   	mcck_backup->ext_damage_code = get_lowcore()->external_damage_code;
>>   	mcck_backup->failing_storage_address = get_lowcore()->failing_storage_address;
>>   }
>> @@ -357,7 +357,7 @@ NOKPROBE_SYMBOL(s390_backup_mcck_info);
>>   #define ED_STP_ISLAND	6	/* External damage STP island check */
>>   #define ED_STP_SYNC	7	/* External damage STP sync check */
>>   
>> -#define MCCK_CODE_NO_GUEST	(MCCK_CODE_CP | MCCK_CODE_EXT_DAMAGE)
>> +#define MCCK_CODE_NO_GUEST	(MCCK_CODE_CP | MCCK_CODE_EXT_DAMAGE | MCCK_CODE_CK)
> 
> it looks like this macro here should have been used above... ^

Yes, see my comment in the cover letter. We would need to move this define.

  reply	other threads:[~2026-08-06 14:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06 12:52 [PATCH 0/1] address one of sashiko pre-existing issues Christian Borntraeger
2026-08-06 12:52 ` [PATCH 1/1] KVM: s390: Fix memory corruption by not reinjecting CK machine checks Christian Borntraeger
2026-08-06 14:20   ` Heiko Carstens
2026-08-06 14:37   ` Claudio Imbrenda
2026-08-06 14:39     ` Christian Borntraeger [this message]
2026-08-06 13:04 ` [PATCH on master] " Christian Borntraeger
2026-08-06 13:16   ` sashiko-bot

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=d32c5862-1e64-496c-bf03-5928c2ea1dfd@linux.ibm.com \
    --to=borntraeger@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=david@kernel.org \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=svens@linux.ibm.com \
    /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 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.