All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Thomas Huth <thuth@redhat.com>, Peter Maydell <peter.maydell@linaro.org>
Cc: "Fam Zheng" <fam@euphon.net>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"open list:S390 general arch..." <qemu-s390x@nongnu.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Laurent Vivier" <laurent@vivier.eu>
Subject: Re: [PATCH] target/s390x: fix s390_probe_access to check PAGE_WRITE_ORG for writeability
Date: Fri, 23 Apr 2021 15:52:31 +0200	[thread overview]
Message-ID: <20210423155231.1f8e2a30.cohuck@redhat.com> (raw)
In-Reply-To: <dae28ff3-5c32-2345-a336-30f59eb59b13@redhat.com>

On Fri, 23 Apr 2021 15:28:19 +0200
Thomas Huth <thuth@redhat.com> wrote:

> On 23/04/2021 15.06, Peter Maydell wrote:
> > On Fri, 23 Apr 2021 at 13:22, Cornelia Huck <cohuck@redhat.com> wrote:  
> >>
> >> On Thu, 22 Apr 2021 16:44:27 +0100
> >> Alex Bennée <alex.bennee@linaro.org> wrote:
> >>  
> >>> We can remove PAGE_WRITE when (internally) marking a page read-only
> >>> because it contains translated code. This can get confused when we are
> >>> executing signal return code on signal stacks.
> >>>
> >>> Fixes: e56552cf07 ("target/s390x: Implement the MVPG condition-code-option bit")
> >>> Found-by: Richard Henderson <richard.henderson@linaro.org>
> >>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >>> Cc: Cornelia Huck <cohuck@redhat.com>
> >>> Cc: Thomas Huth <thuth@redhat.com>
> >>> Cc: David Hildenbrand <david@redhat.com>
> >>> Cc: Laurent Vivier <laurent@vivier.eu>
> >>> ---
> >>>   target/s390x/mem_helper.c | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
> >>> index 12e84a4285..f6a7d29273 100644
> >>> --- a/target/s390x/mem_helper.c
> >>> +++ b/target/s390x/mem_helper.c
> >>> @@ -145,7 +145,7 @@ static int s390_probe_access(CPUArchState *env, target_ulong addr, int size,
> >>>
> >>>   #if defined(CONFIG_USER_ONLY)
> >>>       flags = page_get_flags(addr);
> >>> -    if (!(flags & (access_type == MMU_DATA_LOAD ?  PAGE_READ : PAGE_WRITE))) {
> >>> +    if (!(flags & (access_type == MMU_DATA_LOAD ?  PAGE_READ : PAGE_WRITE_ORG))) {
> >>>           env->__excp_addr = addr;
> >>>           flags = (flags & PAGE_VALID) ? PGM_PROTECTION : PGM_ADDRESSING;
> >>>           if (nonfault) {  
> >>
> >> What's the verdict on this one? I plan to queue this to s390-next; but
> >> if we end up doing an -rc5, it might qualify as a regression fix.  
> > 
> > What's your opinion? I think we do need an rc5 for the network backend
> > hotplug crash. I don't want to open the doors for lots of new fixes
> > just because we've got another rc, but on the other hand this one
> > does look like it's a pretty small and safe fix, and letting intermittent
> > crash bugs out into the wild seems like it could lead to a lot of
> > annoying re-investigation of the same bug if it's reported by users
> > later... So I kind of lean towards putting it in rc5.  
> 
> IMHO: It's in a s390x-only file, within a #ifdef CONFIG_USER_ONLY ... so the 
> damage this could do is very, very limited, indeed. Thus I'd also suggest to 
> include it in a rc5.

Exactly, the benefits outweigh the risk IMHO.

Peter, do you want to pick this one directly, or should I send you a pull req?



  reply	other threads:[~2021-04-23 13:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22 15:44 [PATCH] target/s390x: fix s390_probe_access to check PAGE_WRITE_ORG for writeability Alex Bennée
2021-04-22 16:10 ` Richard Henderson
2021-04-22 16:43 ` David Hildenbrand
2021-04-23 12:22 ` Cornelia Huck
2021-04-23 13:06   ` Peter Maydell
2021-04-23 13:28     ` Thomas Huth
2021-04-23 13:52       ` Cornelia Huck [this message]
2021-04-23 13:56         ` Peter Maydell
2021-04-23 15:44           ` Peter Maydell

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=20210423155231.1f8e2a30.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=aurelien@aurel32.net \
    --cc=berrange@redhat.com \
    --cc=crosa@redhat.com \
    --cc=david@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=fam@euphon.net \
    --cc=laurent@vivier.eu \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@redhat.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 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.