[Cluster-devel] [PATCH v5 00/12] gfs2: Fix mmap + page fault deadlocks
torvalds at linux-foundation.org
Thu Aug 19 20:14:17 UTC 2021
On Thu, Aug 19, 2021 at 12:41 PM Andreas Gruenbacher
<agruenba at redhat.com> wrote:
> Hmm, what if GUP is made to skip VM_IO vmas without adding anything to
> the pages array? That would match fault_in_iov_iter_writeable, which
> is modeled after __mm_populate and which skips VM_IO and VM_PFNMAP
I don't understand what you mean.. GUP already skips VM_IO (and
VM_PFNMAP) pages. It just returns EFAULT.
We could make it return another error. We already have DAX and
FOLL_LONGTERM returning -EOPNOTSUPP.
Of course, I think some code ends up always just returning "number of
pages looked up" and might return 0 for "no pages" rather than the
error for the first page.
So we may end up having interfaces that then lose that explanation
error code, but I didn't check.
But we couldn't make it just say "skip them and try later addresses",
if that is what you meant. THAT makes no sense - that would just make
GUP look up some other address than what was asked for.
> > I also do still think that even regardless of that, we want to just
> > add a FOLL_NOFAULT flag that just disables calling handle_mm_fault(),
> > and then you can use the regular get_user_pages().
> > That at least gives us the full _normal_ page handling stuff.
> And it does fix the generic/208 failure.
Good. So I think the approach is usable, even if we might have corner
So I think the remaining issue is exactly things like VM_IO and
VM_PFNMAP. Do the fstests have test-cases for things like this? It
_is_ quite specialized, it might be a good idea to have that.
Of course, doing direct-IO from special memory regions with zerocopy
might be something special people actually want to do. But I think
we've had that VM_IO flag testing there basically forever, so I don't
think it has ever worked (for some definition of "ever").
More information about the Cluster-devel