similar to: [PATCH v2] xen/gntdev: do not set VM_PFNMAP

Since when we are using the m2p_override it is not true anymore that the mmap''ed area doesn''t have corresponsing struct pages. Removing the VM_PFNMAP flag makes get_user_pages work on the mmap''ed user vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT. The patch should be backported back to 2.6.38.

The only time when granted pages need to be treated specially is when using Xen''s PTE modification for grant mappings owned by another domain. Otherwise, the area does not require VM_DONTCOPY and VM_PFNMAP, since it can be accessed just like any other page of RAM. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- drivers/xen/gntalloc.c | 14 ++++++++++++--

This flag controls the meaning of gnttab_map_grant_ref.host_addr and specifies that the field contains a refernce to the pte entry to be used to perform the mapping. Therefore move the use of this flag to the point at which we actually use a reference to the pte instead of something else, splitting up the usage of the flag in this way is confusing and potentially error prone. The other flags are

On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > gntdev simply wants to monitor a specific VMA for any notifier events, > this can be done straightforwardly using mmu_range_notifier_insert() over > the VMA's VA range. > > The notifier should be attached until the original VMA is destroyed. > > It is unclear if any of

From: Jason Gunthorpe <jgg at mellanox.com> gntdev simply wants to monitor a specific VMA for any notifier events, this can be done straightforwardly using mmu_range_notifier_insert() over the VMA's VA range. The notifier should be attached until the original VMA is destroyed. It is unclear if any of this is even sane, but at least a lot of duplicate code is removed. Cc: Oleksandr

We should unlock here and also decrement the number of &map->users. Signed-off-by: Dan Carpenter <error27 at gmail.com> --- I'm not very familiar with this code. Please review carefully. diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 017ce60..b0f9e8f 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -662,7 +662,7 @@ static int gntdev_mmap(struct

We should unlock here and also decrement the number of &map->users. Signed-off-by: Dan Carpenter <error27 at gmail.com> --- I'm not very familiar with this code. Please review carefully. diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 017ce60..b0f9e8f 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -662,7 +662,7 @@ static int gntdev_mmap(struct

We should unlock here and also decrement the number of &map->users. Signed-off-by: Dan Carpenter <error27 at gmail.com> --- I'm not very familiar with this code. Please review carefully. diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 017ce60..b0f9e8f 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -662,7 +662,7 @@ static int gntdev_mmap(struct

On 11/4/19 9:31 PM, Jason Gunthorpe wrote: > On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote: >> On 10/28/19 4:10 PM, Jason Gunthorpe wrote: >>> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma) >>> struct gntdev_priv *priv = file->private_data; >>> >>> pr_debug("gntdev_vma_close %p\n",

On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma) > struct gntdev_priv *priv = file->private_data; > > pr_debug("gntdev_vma_close %p\n", vma); > - if (use_ptemod) { > - /* It is possible that an mmu notifier could be running > - * concurrently, so take priv->lock to ensure that

direct_remap_pfn_range() does not properly mark vma with VM_PFNMAP. This triggers improper reference counting on what rmap thought was a normal page, and a subsequent BUG() such as: Eeek! page_mapcount(page) went negative! (-1) page->flags = 414 page->count = 1 page->mapping = 00000000 ------------[ cut here ]------------ kernel BUG at

On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote: > > So, I suppose it can be relaxed to a null test and a WARN_ON that it > > hasn't changed? > > You mean > > if (use_ptemod) { > ??????? WARN_ON(map->vma != vma); > ??????? ... > > > Yes, that sounds good. I amended my copy of the patch with the above, has this rework shown signs

On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote: > On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > > @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma) > > struct gntdev_priv *priv = file->private_data; > > > > pr_debug("gntdev_vma_close %p\n", vma); > > - if (use_ptemod) { > > - /* It is possible

On 11/7/19 3:36 PM, Jason Gunthorpe wrote: > On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote: > >>> So, I suppose it can be relaxed to a null test and a WARN_ON that it >>> hasn't changed? >> You mean >> >> if (use_ptemod) { >> ??????? WARN_ON(map->vma != vma); >> ??????? ... >> >> >> Yes, that sounds

On 27/02/14 15:55, Zoltan Kiss wrote: > (This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override > during mapping") > > The grant mapping API does m2p_override unnecessarily: only gntdev needs it, > for blkback and future netback patches it just cause a lock contention, as > those pages never go to userspace. Therefore this series does the following:

On Wed, Oct 30, 2019 at 12:55:37PM -0400, Boris Ostrovsky wrote: > On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > > From: Jason Gunthorpe <jgg at mellanox.com> > > > > gntdev simply wants to monitor a specific VMA for any notifier events, > > this can be done straightforwardly using mmu_range_notifier_insert() over > > the VMA's VA range. > > >

Package: blktap-dkms Version: 2.0.93-0.1 Severity: serious Justification: fails to build from source (but built successfully in the past) blktap fails to build on kernel 3.13 and probably older kernels as well. According to this bug: https://bugs.launchpad.net/ubuntu/+source/blktap-dkms/+bug/1245009 VM_RESERVED is deprecated as of 3.7. Building with the patch described in that bug allows for

(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override during mapping") The grant mapping API does m2p_override unnecessarily: only gntdev needs it, for blkback and future netback patches it just cause a lock contention, as those pages never go to userspace. Therefore this series does the following: - the bulk of the original function (everything after the mapping

(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override during mapping") The grant mapping API does m2p_override unnecessarily: only gntdev needs it, for blkback and future netback patches it just cause a lock contention, as those pages never go to userspace. Therefore this series does the following: - the bulk of the original function (everything after the mapping

Hi, > > - /* VM_PFNMAP was set by drm_gem_mmap() */ > > - vma->vm_flags &= ~VM_PFNMAP; > > - vma->vm_flags |= VM_MIXEDMAP; > > + vma->vm_flags |= (VM_MIXEDMAP|VM_DONTEXPAND); > > I'm finding this a bit hard to follow - but I think here we've lost > VM_IO and VM_DONTDUMP which used to be set by drm_gem_mmap(). Yep. Intentional, but I think I