From: Peter Xu <peterx@redhat.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Alex Williamson <alex.williamson@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
cohuck@redhat.com, cai@lca.pw
Subject: Re: [PATCH v3 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
Date: Mon, 25 May 2020 10:28:06 -0400 [thread overview]
Message-ID: <20200525142806.GC1058657@xz-x1> (raw)
In-Reply-To: <20200525122607.GC744@ziepe.ca>
On Mon, May 25, 2020 at 09:26:07AM -0300, Jason Gunthorpe wrote:
> On Sat, May 23, 2020 at 07:52:57PM -0400, Peter Xu wrote:
>
> > For what I understand now, IMHO we should still need all those handlings of
> > FAULT_FLAG_RETRY_NOWAIT like in the initial version. E.g., IIUC KVM gup will
> > try with FOLL_NOWAIT when async is allowed, before the complete slow path. I'm
> > not sure what would be the side effect of that if fault() blocked it. E.g.,
> > the caller could be in an atomic context.
>
> AFAICT FAULT_FLAG_RETRY_NOWAIT only impacts what happens when
> VM_FAULT_RETRY is returned, which this doesn't do?
Yes, that's why I think we should still properly return VM_FAULT_RETRY if
needed.. because IMHO it is still possible that the caller calls with
FAULT_FLAG_RETRY_NOWAIT.
My understanding is that FAULT_FLAG_RETRY_NOWAIT majorly means:
- We cannot release the mmap_sem, and,
- We cannot sleep
But we're allowed to return VM_FAULT_RETRY if any of the above is necessary.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2020-05-25 14:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 19:17 [PATCH v3 0/3] vfio-pci: Block user access to disabled device MMIO Alex Williamson
2020-05-22 19:17 ` [PATCH v3 1/3] vfio/type1: Support faulting PFNMAP vmas Alex Williamson
2020-05-22 19:17 ` [PATCH v3 2/3] vfio-pci: Fault mmaps to enable vma tracking Alex Williamson
2020-05-22 19:17 ` [PATCH v3 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory Alex Williamson
2020-05-23 19:34 ` Peter Xu
2020-05-23 23:06 ` Alex Williamson
2020-05-23 23:52 ` Peter Xu
2020-05-24 0:02 ` Peter Xu
2020-05-25 12:26 ` Jason Gunthorpe
2020-05-25 14:28 ` Peter Xu [this message]
2020-05-25 14:46 ` Jason Gunthorpe
2020-05-25 15:11 ` Peter Xu
2020-05-25 16:56 ` Jason Gunthorpe
2020-05-25 20:56 ` John Hubbard
2020-05-26 0:37 ` Jason Gunthorpe
2020-05-26 0:46 ` John Hubbard
2020-05-26 13:49 ` Peter Xu
2020-05-26 14:32 ` Alex Williamson
2020-05-26 14:46 ` Peter Xu
2020-05-26 15:53 ` Jason Gunthorpe
2020-05-26 15:57 ` Alex Williamson
2020-05-22 22:08 ` [PATCH v3 0/3] vfio-pci: Block user access to disabled device MMIO Qian Cai
2020-05-22 22:25 ` Alex Williamson
-- strict thread matches above, loose matches on Subject: below --
2020-05-25 10:09 [PATCH v3 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory kbuild test robot
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=20200525142806.GC1058657@xz-x1 \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=cai@lca.pw \
--cc=cohuck@redhat.com \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@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.