All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Cc: david@redhat.com, gor@linux.ibm.com, hca@linux.ibm.com,
	stable@vger.kernel.org
Subject: Re: [PATCH 4.9] s390/mm: do not trigger write fault when vma does not allow VM_WRITE
Date: Thu, 1 Sep 2022 12:12:29 +0200	[thread overview]
Message-ID: <YxCFjWQ1BAT6+Evj@kroah.com> (raw)
In-Reply-To: <20220829155238.3865621-1-gerald.schaefer@linux.ibm.com>

On Mon, Aug 29, 2022 at 05:52:38PM +0200, Gerald Schaefer wrote:
> commit 41ac42f137080bc230b5882e3c88c392ab7f2d32 upstream.
> 
> For non-protection pXd_none() page faults in do_dat_exception(), we
> call do_exception() with access == (VM_READ | VM_WRITE | VM_EXEC).
> In do_exception(), vma->vm_flags is checked against that before
> calling handle_mm_fault().
> 
> Since commit 92f842eac7ee3 ("[S390] store indication fault optimization"),
> we call handle_mm_fault() with FAULT_FLAG_WRITE, when recognizing that
> it was a write access. However, the vma flags check is still only
> checking against (VM_READ | VM_WRITE | VM_EXEC), and therefore also
> calling handle_mm_fault() with FAULT_FLAG_WRITE in cases where the vma
> does not allow VM_WRITE.
> 
> Fix this by changing access check in do_exception() to VM_WRITE only,
> when recognizing write access.
> 
> Link: https://lkml.kernel.org/r/20220811103435.188481-3-david@redhat.com
> Fixes: 92f842eac7ee3 ("[S390] store indication fault optimization")
> Cc: <stable@vger.kernel.org>
> Reported-by: David Hildenbrand <david@redhat.com>
> Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
> Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
> ---
>  arch/s390/mm/fault.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> index ba2f21873cbd..6fa4220e34b5 100644
> --- a/arch/s390/mm/fault.c
> +++ b/arch/s390/mm/fault.c
> @@ -409,7 +409,9 @@ static inline int do_exception(struct pt_regs *regs, int access)
>  	flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
>  	if (user_mode(regs))
>  		flags |= FAULT_FLAG_USER;
> -	if (access == VM_WRITE || (trans_exc_code & store_indication) == 0x400)
> +	if ((trans_exc_code & store_indication) == 0x400)
> +		access = VM_WRITE;
> +	if (access == VM_WRITE)
>  		flags |= FAULT_FLAG_WRITE;
>  	down_read(&mm->mmap_sem);
>  
> -- 
> 2.34.1
> 

all now queued up, thanks.

greg k-h

      reply	other threads:[~2022-09-01 10:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-29  7:37 FAILED: patch "[PATCH] s390/mm: do not trigger write fault when vma does not allow" failed to apply to 4.9-stable tree gregkh
2022-08-29 15:52 ` [PATCH 4.9] s390/mm: do not trigger write fault when vma does not allow VM_WRITE Gerald Schaefer
2022-09-01 10:12   ` Greg KH [this message]

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=YxCFjWQ1BAT6+Evj@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=david@redhat.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    /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.