All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Bayer <gbayer@linux.ibm.com>
To: Liu Dalin <liudalin@kylinsec.com.cn>,
	Niklas Schnelle	 <schnelle@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Matthew Rosato	 <mjrosato@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle	 <svens@linux.ibm.com>,
	linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	Deng Yingchao <dengyingchao@kylinsec.com.cn>,
	Qin Yungao <qinyungao@kylinsec.com.cn>,
	Luo Qiu	 <luoqiu@kylinsec.com.cn>
Subject: Re: [PATCH] arch/s390/pci: fix fixup_user_fault() calls with NULL unlocked parameter
Date: Mon, 07 Sep 2026 17:25:04 +0200	[thread overview]
Message-ID: <98f11271b6574aa945755f073a3bcec8f69a02e9.camel@linux.ibm.com> (raw)
In-Reply-To: <0726CF177011E0E2+20260826064228.3255764-1-liudalin@kylinsec.com.cn>

On Wed, 2026-08-26 at 14:42 +0800, Liu Dalin wrote:
> The s390 PCI MMIO functions call fixup_user_fault() with the 'unlocked'
> parameter set to NULL. This means when handle_mm_fault() returns
> VM_FAULT_COMPLETED or VM_FAULT_RETRY, the function re-acquires the
> mmap_lock but cannot notify the caller about this state change.

Hi Liu,

I'm far from being a mm-expert, but from reading the function
description of fixup_user_fault() in mm/gup.c I believe that mmap_lock
is unlocked *only* if retries are allowed by way of setting the
FAULT_FLAG_ALLOW_RETRY. Otherwise, the unlocked parameter is allowed to
be NULL.

Since s390_pci_mmio_write()/_read() calls fixup_user_fault() without
the FAULT_FLAG_ALLOW_RETRY flag, I thought your patch is not needed.

But then I got concerned about the comment in the handling of the
VM_FAULT_COMPLETED return from handle_mm_fault() - which got introduced
with commit d92725256b4f ("mm: avoid unnecessary page fault retires on
shared memory types") without changing the documentation of the
unlocked parameter of fixup_user_fault().

I'm under the impression, that so far we saw
s390_pci_mmio_write()/_read() only in use on VMAs that ended in EFAULT?
But that's a question to @Matt and/or @Niklas...

> This is problematic because the caller subsequently calls
> mmap_read_unlock() at the end of the function. If the lock was
> re-acquired inside fixup_user_fault(), the unlock happens correctly.
> But passing NULL makes the code fragile and hard to reason about.

For a full solution, this would have to make the call to
mmap_read_lock() dependent on unlocked being true at the end of both
sys-calls.

> 
> Fix this by providing a proper 'unlocked' variable to fixup_user_fault()
> so the lock state is properly tracked.
> 
> This is a follow-up to the defensive NULL check added in fixup_user_fault()
> by the previous patch in this series.
> 
> Fixes: 41a0926e82f4 ("s390/pci: Fix s390_mmio_read/write syscall page fault handling")
> Signed-off-by: Liu Dalin <liudalin@kylinsec.com.cn>
> ---
>  arch/s390/pci/pci_mmio.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
> index f3f79ba78410..5ef2d6436d4b 100644
> --- a/arch/s390/pci/pci_mmio.c
> +++ b/arch/s390/pci/pci_mmio.c
> @@ -182,7 +182,9 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
>  	args.vma = vma;
>  	ret = follow_pfnmap_start(&args);
>  	if (ret) {
> -		fixup_user_fault(current->mm, mmio_addr, FAULT_FLAG_WRITE, NULL);
> +		bool unlocked = false;
> +
> +		fixup_user_fault(current->mm, mmio_addr, FAULT_FLAG_WRITE, &unlocked);
>  		ret = follow_pfnmap_start(&args);
>  		if (ret)
>  			goto out_unlock_mmap;
> @@ -335,7 +337,9 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr,
>  	args.address = mmio_addr;
>  	ret = follow_pfnmap_start(&args);
>  	if (ret) {
> -		fixup_user_fault(current->mm, mmio_addr, 0, NULL);
> +		bool unlocked = false;
> +
> +		fixup_user_fault(current->mm, mmio_addr, 0, &unlocked);
>  		ret = follow_pfnmap_start(&args);
>  		if (ret)
>  			goto out_unlock_mmap;

Thank you,
Gerd

      parent reply	other threads:[~2026-09-07 15:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26  6:42 [PATCH] arch/s390/pci: fix fixup_user_fault() calls with NULL unlocked parameter Liu Dalin
2026-08-26  6:51 ` sashiko-bot
2026-09-07 15:25 ` Gerd Bayer [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=98f11271b6574aa945755f073a3bcec8f69a02e9.camel@linux.ibm.com \
    --to=gbayer@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=dengyingchao@kylinsec.com.cn \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=liudalin@kylinsec.com.cn \
    --cc=luoqiu@kylinsec.com.cn \
    --cc=mjrosato@linux.ibm.com \
    --cc=qinyungao@kylinsec.com.cn \
    --cc=schnelle@linux.ibm.com \
    --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.