public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Janosch Frank <frankja@linux.ibm.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	thuth@redhat.com, david@redhat.com, imbrenda@linux.ibm.com,
	cohuck@redhat.com, linux-s390@vger.kernel.org, gor@linux.ibm.com,
	mihajlov@linux.ibm.com
Subject: Re: [PATCH 2/2] s390: mm: Fix secure storage access exception handling
Date: Wed, 20 Jan 2021 14:42:08 +0100	[thread overview]
Message-ID: <20210120134208.GC8202@osiris> (raw)
In-Reply-To: <3e1978c6-4462-1de6-e1aa-e664ffa633c1@de.ibm.com>

On Tue, Jan 19, 2021 at 11:25:01AM +0100, Christian Borntraeger wrote:
> > +		if (user_mode(regs)) {
> > +			send_sig(SIGSEGV, current, 0);
> > +			return;
> > +		} else
> > +			panic("Unexpected PGM 0x3d with TEID bit 61=0");
> 
> use BUG instead of panic? That would kill this process, but it allows
> people to maybe save unaffected data.

It would kill the process, and most likely lead to deadlock'ed
system. But with all the "good" debug information being lost, which
wouldn't be the case with panic().
I really don't think this is a good idea.

  parent reply	other threads:[~2021-01-20 22:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 10:04 [PATCH 0/2] s390: uv: small UV fixes Janosch Frank
2021-01-19 10:04 ` [PATCH 1/2] s390: uv: Fix sysfs max number of VCPUs reporting Janosch Frank
2021-01-19 10:11   ` Christian Borntraeger
2021-01-19 10:15     ` Janosch Frank
2021-01-19 10:19       ` Christian Borntraeger
2021-01-19 13:11   ` Claudio Imbrenda
2021-01-19 16:19   ` Cornelia Huck
2021-01-19 10:04 ` [PATCH 2/2] s390: mm: Fix secure storage access exception handling Janosch Frank
2021-01-19 10:25   ` Christian Borntraeger
2021-01-19 10:38     ` Janosch Frank
2021-01-19 16:24       ` Cornelia Huck
2021-01-20 13:42     ` Heiko Carstens [this message]
2021-01-20 14:39       ` Christian Borntraeger
2021-01-20 15:24         ` Heiko Carstens
2021-01-19 13:09   ` Claudio Imbrenda

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=20210120134208.GC8202@osiris \
    --to=hca@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mihajlov@linux.ibm.com \
    --cc=thuth@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox