* [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction @ 2020-08-21 8:50 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 8:50 UTC (permalink / raw) To: linux-kernel, intel-gfx Cc: linux-mm, Chris Wilson, Pavel Machek, Andrew Morton, Joerg Roedel, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable The alloc_vm_area() is another method for drivers to vmap/map_kernel_range that uses apply_to_page_range() rather than the direct vmalloc walkers. This is missing the page table modification tracking, and the ability to synchronize the PTE updates afterwards. Provide flush_vm_area() for the users of alloc_vm_area() that assumes the worst and ensures that the page directories are correctly flushed upon construction. The impact is most pronounced on x86_32 due to the delayed set_pmd(). Reported-by: Pavel Machek <pavel@ucw.cz> References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Joerg Roedel <jroedel@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: David Vrabel <david.vrabel@citrix.com> Cc: <stable@vger.kernel.org> # v5.8+ --- include/linux/vmalloc.h | 1 + mm/vmalloc.c | 16 ++++++++++++++++ 2 files changed, 17 insertions(+) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 0221f852a7e1..a253b27df0ac 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr) /* Allocate/destroy a 'vmalloc' VM area. */ extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); +extern void flush_vm_area(struct vm_struct *area); extern void free_vm_area(struct vm_struct *area); /* for /dev/kmem */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index b482d240f9a2..c41934486031 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) } EXPORT_SYMBOL_GPL(alloc_vm_area); +void flush_vm_area(struct vm_struct *area) +{ + unsigned long addr = (unsigned long)area->addr; + + /* apply_to_page_range() doesn't track the damage, assume the worst */ + if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED | + PGTBL_PMD_MODIFIED | + PGTBL_PUD_MODIFIED | + PGTBL_P4D_MODIFIED | + PGTBL_PGD_MODIFIED)) + arch_sync_kernel_mappings(addr, addr + area->size); + + flush_cache_vmap(addr, area->size); +} +EXPORT_SYMBOL_GPL(flush_vm_area); + void free_vm_area(struct vm_struct *area) { struct vm_struct *ret; -- 2.20.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [Intel-gfx] [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction @ 2020-08-21 8:50 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 8:50 UTC (permalink / raw) To: linux-kernel, intel-gfx Cc: Joerg Roedel, stable, Chris Wilson, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds The alloc_vm_area() is another method for drivers to vmap/map_kernel_range that uses apply_to_page_range() rather than the direct vmalloc walkers. This is missing the page table modification tracking, and the ability to synchronize the PTE updates afterwards. Provide flush_vm_area() for the users of alloc_vm_area() that assumes the worst and ensures that the page directories are correctly flushed upon construction. The impact is most pronounced on x86_32 due to the delayed set_pmd(). Reported-by: Pavel Machek <pavel@ucw.cz> References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Joerg Roedel <jroedel@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: David Vrabel <david.vrabel@citrix.com> Cc: <stable@vger.kernel.org> # v5.8+ --- include/linux/vmalloc.h | 1 + mm/vmalloc.c | 16 ++++++++++++++++ 2 files changed, 17 insertions(+) diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index 0221f852a7e1..a253b27df0ac 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr) /* Allocate/destroy a 'vmalloc' VM area. */ extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); +extern void flush_vm_area(struct vm_struct *area); extern void free_vm_area(struct vm_struct *area); /* for /dev/kmem */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index b482d240f9a2..c41934486031 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) } EXPORT_SYMBOL_GPL(alloc_vm_area); +void flush_vm_area(struct vm_struct *area) +{ + unsigned long addr = (unsigned long)area->addr; + + /* apply_to_page_range() doesn't track the damage, assume the worst */ + if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED | + PGTBL_PMD_MODIFIED | + PGTBL_PUD_MODIFIED | + PGTBL_P4D_MODIFIED | + PGTBL_PGD_MODIFIED)) + arch_sync_kernel_mappings(addr, addr + area->size); + + flush_cache_vmap(addr, area->size); +} +EXPORT_SYMBOL_GPL(flush_vm_area); + void free_vm_area(struct vm_struct *area) { struct vm_struct *ret; -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [PATCH 2/4] drm/i915/gem: Sync the vmap PTEs upon construction 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 8:50 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 8:50 UTC (permalink / raw) To: linux-kernel, intel-gfx Cc: linux-mm, Chris Wilson, Pavel Machek, Andrew Morton, Joerg Roedel, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, stable Since synchronising the PTE after assignment is a manual step, use the newly exported interface to flush the PTE after assigning via alloc_vm_area(). Reported-by: Pavel Machek <pavel@ucw.cz> References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Joerg Roedel <jroedel@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: <stable@vger.kernel.org> # v5.8+ --- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c index 7050519c87a4..0fee67f34d74 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c @@ -304,6 +304,7 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj, for_each_sgt_daddr(addr, iter, sgt) **ptes++ = iomap_pte(iomap, addr, pgprot); } + flush_vm_area(area); if (mem != stack) kvfree(mem); -- 2.20.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [Intel-gfx] [PATCH 2/4] drm/i915/gem: Sync the vmap PTEs upon construction @ 2020-08-21 8:50 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 8:50 UTC (permalink / raw) To: linux-kernel, intel-gfx Cc: Joerg Roedel, stable, Chris Wilson, linux-mm, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds Since synchronising the PTE after assignment is a manual step, use the newly exported interface to flush the PTE after assigning via alloc_vm_area(). Reported-by: Pavel Machek <pavel@ucw.cz> References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Joerg Roedel <jroedel@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: <stable@vger.kernel.org> # v5.8+ --- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c index 7050519c87a4..0fee67f34d74 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c @@ -304,6 +304,7 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj, for_each_sgt_daddr(addr, iter, sgt) **ptes++ = iomap_pte(iomap, addr, pgprot); } + flush_vm_area(area); if (mem != stack) kvfree(mem); -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH 2/4] drm/i915/gem: Sync the vmap PTEs upon construction 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson (?) @ 2020-08-21 12:41 ` Linus Torvalds -1 siblings, 0 replies; 40+ messages in thread From: Linus Torvalds @ 2020-08-21 12:41 UTC (permalink / raw) To: Chris Wilson Cc: Linux Kernel Mailing List, intel-gfx, Linux-MM, Pavel Machek, Andrew Morton, Joerg Roedel, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, stable On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson <chris@chris-wilson.co.uk> wrote: > > Since synchronising the PTE after assignment is a manual step, use the > newly exported interface to flush the PTE after assigning via > alloc_vm_area(). This commit message doesn't make much sense to me. Are you talking about synchronizing the page directory structure across processes after possibly creating new kernel page tables? Because that has nothing to do with the PTE. It's all about making sure the _upper_ layers of the page directories are populated everywhere.. The name seems off to me too - what are you "flushing"? (And yes, I know about the flush_cache_vmap(), but that looks just bogus, since any non-mapped area shouldn't have any virtual caches to begin with, so I suspect that is just the crazy architectures being confused - flush_cache_vmap() is a no-op on any sane architecture - and powerpc that mis-uses it for other things). Linus ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH 2/4] drm/i915/gem: Sync the vmap PTEs upon construction @ 2020-08-21 12:41 ` Linus Torvalds 0 siblings, 0 replies; 40+ messages in thread From: Linus Torvalds @ 2020-08-21 12:41 UTC (permalink / raw) To: Chris Wilson Cc: Joerg Roedel, intel-gfx, Linux Kernel Mailing List, stable, Linux-MM, Pavel Machek, Dave Airlie, Andrew Morton On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson <chris@chris-wilson.co.uk> wrote: > > Since synchronising the PTE after assignment is a manual step, use the > newly exported interface to flush the PTE after assigning via > alloc_vm_area(). This commit message doesn't make much sense to me. Are you talking about synchronizing the page directory structure across processes after possibly creating new kernel page tables? Because that has nothing to do with the PTE. It's all about making sure the _upper_ layers of the page directories are populated everywhere.. The name seems off to me too - what are you "flushing"? (And yes, I know about the flush_cache_vmap(), but that looks just bogus, since any non-mapped area shouldn't have any virtual caches to begin with, so I suspect that is just the crazy architectures being confused - flush_cache_vmap() is a no-op on any sane architecture - and powerpc that mis-uses it for other things). Linus _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 2/4] drm/i915/gem: Sync the vmap PTEs upon construction @ 2020-08-21 12:41 ` Linus Torvalds 0 siblings, 0 replies; 40+ messages in thread From: Linus Torvalds @ 2020-08-21 12:41 UTC (permalink / raw) To: Chris Wilson Cc: Linux Kernel Mailing List, intel-gfx, Linux-MM, Pavel Machek, Andrew Morton, Joerg Roedel, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, stable On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson <chris@chris-wilson.co.uk> wrote: > > Since synchronising the PTE after assignment is a manual step, use the > newly exported interface to flush the PTE after assigning via > alloc_vm_area(). This commit message doesn't make much sense to me. Are you talking about synchronizing the page directory structure across processes after possibly creating new kernel page tables? Because that has nothing to do with the PTE. It's all about making sure the _upper_ layers of the page directories are populated everywhere.. The name seems off to me too - what are you "flushing"? (And yes, I know about the flush_cache_vmap(), but that looks just bogus, since any non-mapped area shouldn't have any virtual caches to begin with, so I suspect that is just the crazy architectures being confused - flush_cache_vmap() is a no-op on any sane architecture - and powerpc that mis-uses it for other things). Linus ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 2/4] drm/i915/gem: Sync the vmap PTEs upon construction 2020-08-21 12:41 ` Linus Torvalds @ 2020-08-21 13:01 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 13:01 UTC (permalink / raw) To: Linus Torvalds Cc: Linux Kernel Mailing List, intel-gfx, Linux-MM, Pavel Machek, Andrew Morton, Joerg Roedel, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, stable Quoting Linus Torvalds (2020-08-21 13:41:03) > On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson <chris@chris-wilson.co.uk> wrote: > > > > Since synchronising the PTE after assignment is a manual step, use the > > newly exported interface to flush the PTE after assigning via > > alloc_vm_area(). > > This commit message doesn't make much sense to me. > > Are you talking about synchronizing the page directory structure > across processes after possibly creating new kernel page tables? > > Because that has nothing to do with the PTE. It's all about making > sure the _upper_ layers of the page directories are populated > everywhere.. > > The name seems off to me too - what are you "flushing"? (And yes, I > know about the flush_cache_vmap(), but that looks just bogus, since > any non-mapped area shouldn't have any virtual caches to begin with, > so I suspect that is just the crazy architectures being confused - > flush_cache_vmap() is a no-op on any sane architecture - and powerpc > that mis-uses it for other things). I was trying to mimic map_kernel_range() which does the arch_sync_kernel_mappings and flush_cache_vmap on top of the apply_to_page_range performed by alloc_vm_area, because buried away in there, on x86-32, is a set_pmd(). Since map_kernel_range() wrapped map_kernel_range_noflush(), flush seemed like the right verb. Joerg pointed out that the sync belonged to __apply_to_page_range and fixed it in situ. -Chris ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH 2/4] drm/i915/gem: Sync the vmap PTEs upon construction @ 2020-08-21 13:01 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 13:01 UTC (permalink / raw) To: Linus Torvalds Cc: Joerg Roedel, intel-gfx, Linux Kernel Mailing List, stable, Linux-MM, Pavel Machek, Dave Airlie, Andrew Morton Quoting Linus Torvalds (2020-08-21 13:41:03) > On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson <chris@chris-wilson.co.uk> wrote: > > > > Since synchronising the PTE after assignment is a manual step, use the > > newly exported interface to flush the PTE after assigning via > > alloc_vm_area(). > > This commit message doesn't make much sense to me. > > Are you talking about synchronizing the page directory structure > across processes after possibly creating new kernel page tables? > > Because that has nothing to do with the PTE. It's all about making > sure the _upper_ layers of the page directories are populated > everywhere.. > > The name seems off to me too - what are you "flushing"? (And yes, I > know about the flush_cache_vmap(), but that looks just bogus, since > any non-mapped area shouldn't have any virtual caches to begin with, > so I suspect that is just the crazy architectures being confused - > flush_cache_vmap() is a no-op on any sane architecture - and powerpc > that mis-uses it for other things). I was trying to mimic map_kernel_range() which does the arch_sync_kernel_mappings and flush_cache_vmap on top of the apply_to_page_range performed by alloc_vm_area, because buried away in there, on x86-32, is a set_pmd(). Since map_kernel_range() wrapped map_kernel_range_noflush(), flush seemed like the right verb. Joerg pointed out that the sync belonged to __apply_to_page_range and fixed it in situ. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH 3/4] drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 8:50 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 8:50 UTC (permalink / raw) To: linux-kernel, intel-gfx; +Cc: linux-mm, Chris Wilson, Matthew Auld Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(), rather than a direct assignment. Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c index 0fee67f34d74..6838cf9bdae6 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c @@ -286,23 +286,34 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj, } if (i915_gem_object_has_struct_page(obj)) { + unsigned long addr = (unsigned long)area->addr; struct sgt_iter iter; struct page *page; pte_t **ptes = mem; - for_each_sgt_page(page, iter, sgt) - **ptes++ = mk_pte(page, pgprot); + for_each_sgt_page(page, iter, sgt) { + set_pte_at(&init_mm, addr, *ptes, mk_pte(page, pgprot)); + addr += PAGE_SIZE; + ptes++; + } + GEM_BUG_ON(addr != (unsigned long)area->addr + obj->base.size); } else { + unsigned long addr = (unsigned long)area->addr; resource_size_t iomap; struct sgt_iter iter; pte_t **ptes = mem; - dma_addr_t addr; + dma_addr_t offset; iomap = obj->mm.region->iomap.base; iomap -= obj->mm.region->region.start; - for_each_sgt_daddr(addr, iter, sgt) - **ptes++ = iomap_pte(iomap, addr, pgprot); + for_each_sgt_daddr(offset, iter, sgt) { + set_pte_at(&init_mm, addr, *ptes, + iomap_pte(iomap, offset, pgprot)); + addr += PAGE_SIZE; + ptes++; + } + GEM_BUG_ON(addr != (unsigned long)area->addr + obj->base.size); } flush_vm_area(area); -- 2.20.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [Intel-gfx] [PATCH 3/4] drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE @ 2020-08-21 8:50 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 8:50 UTC (permalink / raw) To: linux-kernel, intel-gfx; +Cc: linux-mm, Matthew Auld, Chris Wilson Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(), rather than a direct assignment. Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c b/drivers/gpu/drm/i915/gem/i915_gem_pages.c index 0fee67f34d74..6838cf9bdae6 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c @@ -286,23 +286,34 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj, } if (i915_gem_object_has_struct_page(obj)) { + unsigned long addr = (unsigned long)area->addr; struct sgt_iter iter; struct page *page; pte_t **ptes = mem; - for_each_sgt_page(page, iter, sgt) - **ptes++ = mk_pte(page, pgprot); + for_each_sgt_page(page, iter, sgt) { + set_pte_at(&init_mm, addr, *ptes, mk_pte(page, pgprot)); + addr += PAGE_SIZE; + ptes++; + } + GEM_BUG_ON(addr != (unsigned long)area->addr + obj->base.size); } else { + unsigned long addr = (unsigned long)area->addr; resource_size_t iomap; struct sgt_iter iter; pte_t **ptes = mem; - dma_addr_t addr; + dma_addr_t offset; iomap = obj->mm.region->iomap.base; iomap -= obj->mm.region->region.start; - for_each_sgt_daddr(addr, iter, sgt) - **ptes++ = iomap_pte(iomap, addr, pgprot); + for_each_sgt_daddr(offset, iter, sgt) { + set_pte_at(&init_mm, addr, *ptes, + iomap_pte(iomap, offset, pgprot)); + addr += PAGE_SIZE; + ptes++; + } + GEM_BUG_ON(addr != (unsigned long)area->addr + obj->base.size); } flush_vm_area(area); -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [PATCH 4/4] drm/i915/gem: Replace reloc chain with terminator on error unwind 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 8:50 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 8:50 UTC (permalink / raw) To: linux-kernel, intel-gfx Cc: linux-mm, Chris Wilson, Pavel Machek, Joonas Lahtinen, stable If we hit an error during construction of the reloc chain, we need to replace the chain into the next batch with the terminator so that upon flushing the relocations so far, we do not execute a hanging batch. Reported-by: Pavel Machek <pavel@ucw.cz> Fixes: 964a9b0f611e ("drm/i915/gem: Use chained reloc batches") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: <stable@vger.kernel.org> # v5.8+ --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 31 ++++++++++--------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 24a1486d2dc5..a09f04eee417 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -972,21 +972,6 @@ static int reloc_gpu_chain(struct reloc_cache *cache) if (err) goto out_pool; - GEM_BUG_ON(cache->rq_size + RELOC_TAIL > PAGE_SIZE / sizeof(u32)); - cmd = cache->rq_cmd + cache->rq_size; - *cmd++ = MI_ARB_CHECK; - if (cache->gen >= 8) - *cmd++ = MI_BATCH_BUFFER_START_GEN8; - else if (cache->gen >= 6) - *cmd++ = MI_BATCH_BUFFER_START; - else - *cmd++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT; - *cmd++ = lower_32_bits(batch->node.start); - *cmd++ = upper_32_bits(batch->node.start); /* Always 0 for gen<8 */ - i915_gem_object_flush_map(cache->rq_vma->obj); - i915_gem_object_unpin_map(cache->rq_vma->obj); - cache->rq_vma = NULL; - err = intel_gt_buffer_pool_mark_active(pool, rq); if (err == 0) { i915_vma_lock(batch); @@ -999,15 +984,31 @@ static int reloc_gpu_chain(struct reloc_cache *cache) if (err) goto out_pool; + GEM_BUG_ON(cache->rq_size + RELOC_TAIL > PAGE_SIZE / sizeof(u32)); + cmd = cache->rq_cmd + cache->rq_size; + *cmd++ = MI_ARB_CHECK; + if (cache->gen >= 8) + *cmd++ = MI_BATCH_BUFFER_START_GEN8; + else if (cache->gen >= 6) + *cmd++ = MI_BATCH_BUFFER_START; + else + *cmd++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT; + *cmd++ = lower_32_bits(batch->node.start); + *cmd++ = upper_32_bits(batch->node.start); /* Always 0 for gen<8 */ + cmd = i915_gem_object_pin_map(batch->obj, cache->has_llc ? I915_MAP_FORCE_WB : I915_MAP_FORCE_WC); if (IS_ERR(cmd)) { + /* We will replace the BBS with BBE upon flushing the rq */ err = PTR_ERR(cmd); goto out_pool; } + i915_gem_object_flush_map(cache->rq_vma->obj); + i915_gem_object_unpin_map(cache->rq_vma->obj); + /* Return with batch mapping (cmd) still pinned */ cache->rq_cmd = cmd; cache->rq_size = 0; -- 2.20.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [Intel-gfx] [PATCH 4/4] drm/i915/gem: Replace reloc chain with terminator on error unwind @ 2020-08-21 8:50 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 8:50 UTC (permalink / raw) To: linux-kernel, intel-gfx; +Cc: linux-mm, stable, Pavel Machek, Chris Wilson If we hit an error during construction of the reloc chain, we need to replace the chain into the next batch with the terminator so that upon flushing the relocations so far, we do not execute a hanging batch. Reported-by: Pavel Machek <pavel@ucw.cz> Fixes: 964a9b0f611e ("drm/i915/gem: Use chained reloc batches") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: <stable@vger.kernel.org> # v5.8+ --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 31 ++++++++++--------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 24a1486d2dc5..a09f04eee417 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -972,21 +972,6 @@ static int reloc_gpu_chain(struct reloc_cache *cache) if (err) goto out_pool; - GEM_BUG_ON(cache->rq_size + RELOC_TAIL > PAGE_SIZE / sizeof(u32)); - cmd = cache->rq_cmd + cache->rq_size; - *cmd++ = MI_ARB_CHECK; - if (cache->gen >= 8) - *cmd++ = MI_BATCH_BUFFER_START_GEN8; - else if (cache->gen >= 6) - *cmd++ = MI_BATCH_BUFFER_START; - else - *cmd++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT; - *cmd++ = lower_32_bits(batch->node.start); - *cmd++ = upper_32_bits(batch->node.start); /* Always 0 for gen<8 */ - i915_gem_object_flush_map(cache->rq_vma->obj); - i915_gem_object_unpin_map(cache->rq_vma->obj); - cache->rq_vma = NULL; - err = intel_gt_buffer_pool_mark_active(pool, rq); if (err == 0) { i915_vma_lock(batch); @@ -999,15 +984,31 @@ static int reloc_gpu_chain(struct reloc_cache *cache) if (err) goto out_pool; + GEM_BUG_ON(cache->rq_size + RELOC_TAIL > PAGE_SIZE / sizeof(u32)); + cmd = cache->rq_cmd + cache->rq_size; + *cmd++ = MI_ARB_CHECK; + if (cache->gen >= 8) + *cmd++ = MI_BATCH_BUFFER_START_GEN8; + else if (cache->gen >= 6) + *cmd++ = MI_BATCH_BUFFER_START; + else + *cmd++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT; + *cmd++ = lower_32_bits(batch->node.start); + *cmd++ = upper_32_bits(batch->node.start); /* Always 0 for gen<8 */ + cmd = i915_gem_object_pin_map(batch->obj, cache->has_llc ? I915_MAP_FORCE_WB : I915_MAP_FORCE_WC); if (IS_ERR(cmd)) { + /* We will replace the BBS with BBE upon flushing the rq */ err = PTR_ERR(cmd); goto out_pool; } + i915_gem_object_flush_map(cache->rq_vma->obj); + i915_gem_object_unpin_map(cache->rq_vma->obj); + /* Return with batch mapping (cmd) still pinned */ cache->rq_cmd = cmd; cache->rq_size = 0; -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson ` (3 preceding siblings ...) (?) @ 2020-08-21 9:14 ` Patchwork -1 siblings, 0 replies; 40+ messages in thread From: Patchwork @ 2020-08-21 9:14 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction URL : https://patchwork.freedesktop.org/series/80892/ State : warning == Summary == $ dim checkpatch origin/drm-tip dc5a3f725528 mm: Export flush_vm_area() to sync the PTEs upon construction -:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #17: References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") -:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified")' #17: References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") -:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")' #18: References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()") -:38: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #38: FILE: include/linux/vmalloc.h:207: +extern void flush_vm_area(struct vm_struct *area); total: 2 errors, 1 warnings, 1 checks, 29 lines checked 2410d6d4185d drm/i915/gem: Sync the vmap PTEs upon construction -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") -:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified")' #11: References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") total: 1 errors, 1 warnings, 0 checks, 7 lines checked 6dc443ae9dba drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE 9e1d77a3e2fa drm/i915/gem: Replace reloc chain with terminator on error unwind _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson ` (4 preceding siblings ...) (?) @ 2020-08-21 9:16 ` Patchwork -1 siblings, 0 replies; 40+ messages in thread From: Patchwork @ 2020-08-21 9:16 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction URL : https://patchwork.freedesktop.org/series/80892/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:600:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:617:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:621:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:623:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:630:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:632:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:644:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:648:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:650:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:657:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:659:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:662:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:664:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:676:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:688:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:691:47: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:697:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:796:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:797:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:800:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:801:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:804:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:805:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:812:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:813:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:816:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:817:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:820:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:821:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:828:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:829:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:832:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:833:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:836:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:837:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:844:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:845:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:848:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:849:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:852:46: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:853:40: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:916:47: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:918:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:920:52: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:934:47: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:936:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:938:52: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:956:47: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:958:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:960:52: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:328:34: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:365:34: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:395:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:397:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:404:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:418:40: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:441:40: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:44:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:482:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:486:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:489:61: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:490:64: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:492:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:518:17: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:521:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:64:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:80:17: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:80:17: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:80:17: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:85:30: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:86:24: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c:98:39: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:222:29: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:226:37: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:226:37: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:226:37: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:227:37: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:233:43: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:236:44: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:239:51: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:458:41: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:458:41: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:458:41: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:464:39: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:465:30: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:466:39: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:468:24: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:140:26: expected unsigned long long [usertype] *chunk_array_user +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:140:26: got void [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:140:26: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:141:41: expected void const [noderef] __user *from +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:141:41: got unsigned long long [usertype] *chunk_array_user +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:141:41: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:160:27: expected struct drm_amdgpu_cs_chunk [noderef] __user **chunk_ptr +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:160:27: got void [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:160:27: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1613:21: expected struct drm_amdgpu_fence *fences_user +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1613:21: got void [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1613:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1614:36: expected void const [noderef] __user *from +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1614:36: got struct drm_amdgpu_fence *fences_user +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1614:36: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:161:49: expected void const [noderef] __user *from +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:161:49: got struct drm_amdgpu_cs_chunk [noderef] __user **chunk_ptr +drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:161:49: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1357:25: error: incompatible types in comparison expression (different address spaces): +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1357:25: struct dma_fence * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1357:25: struct dma_fence [noderef] __rcu * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1358:17: error: incompatible types in comparison expression (different address spaces): +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1358:17: struct dma_fence * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1358:17: struct dma_fence [noderef] __rcu * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:138:17: expected restricted __poll_t ( *poll )( ... ) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:138:17: got unsigned int ( * )( ... ) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:138:17: warning: incorrect type in initializer (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1417:17: error: incompatible types in comparison expression (different address spaces): +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1417:17: struct dma_fence * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1417:17: struct dma_fence [noderef] __rcu * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:261:29: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:263:29: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:354:21: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:412:21: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:473:21: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:531:21: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:592:21: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:650:21: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: expected void const volatile [noderef] __user * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: got unsigned int [usertype] * +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: warning: cast removes address space '__user' of expression +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:747:21: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1666:65: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1674:55: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1675:50: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1676:50: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1677:56: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1679:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1680:45: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1681:51: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1682:55: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1683:57: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1685:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1686:53: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1688:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1690:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1691:46: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1695:73: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1697:33: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1699:33: warning: cast to restricted __le32 +drivers/gpu/drm/amd/ _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson ` (5 preceding siblings ...) (?) @ 2020-08-21 9:29 ` Patchwork -1 siblings, 0 replies; 40+ messages in thread From: Patchwork @ 2020-08-21 9:29 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 4555 bytes --] == Series Details == Series: series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction URL : https://patchwork.freedesktop.org/series/80892/ State : success == Summary == CI Bug Log - changes from CI_DRM_8911 -> Patchwork_18386 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/index.html Known issues ------------ Here are the changes found in Patchwork_18386 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@i915_module_load@reload: - fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/fi-tgl-u2/igt@i915_module_load@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/fi-tgl-u2/igt@i915_module_load@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html * igt@i915_selftest@live@execlists: - fi-icl-y: [PASS][5] -> [INCOMPLETE][6] ([i915#2276]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/fi-icl-y/igt@i915_selftest@live@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/fi-icl-y/igt@i915_selftest@live@execlists.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/fi-kbl-x1275/igt@kms_busy@basic@flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/fi-kbl-x1275/igt@kms_busy@basic@flip.html #### Possible fixes #### * igt@i915_selftest@live@gt_lrc: - fi-tgl-u2: [DMESG-FAIL][9] ([i915#2373]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html #### Warnings #### * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) -> [DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/fi-kbl-x1275/igt@kms_force_connector_basic@force-edid.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/fi-kbl-x1275/igt@kms_force_connector_basic@force-edid.html * igt@kms_force_connector_basic@prune-stale-modes: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][14] ([i915#62] / [i915#92]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276 [i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (38 -> 34) ------------------------------ Missing (4): fi-byt-clapper fi-ilk-m540 fi-byt-squawks fi-bsw-cyan Build changes ------------- * Linux: CI_DRM_8911 -> Patchwork_18386 CI-20190529: 20190529 CI_DRM_8911: a1029718e0c12c304c20384a838b02c95f6262d5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5769: 4e5f76be680b65780204668e302026cf638decc9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18386: 9e1d77a3e2faac6f5624fe505f2af1b80357ebf3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9e1d77a3e2fa drm/i915/gem: Replace reloc chain with terminator on error unwind 6dc443ae9dba drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE 2410d6d4185d drm/i915/gem: Sync the vmap PTEs upon construction dc5a3f725528 mm: Export flush_vm_area() to sync the PTEs upon construction == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/index.html [-- Attachment #1.2: Type: text/html, Size: 6045 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 9:51 ` Joerg Roedel -1 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 9:51 UTC (permalink / raw) To: Chris Wilson Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote: > The alloc_vm_area() is another method for drivers to > vmap/map_kernel_range that uses apply_to_page_range() rather than the > direct vmalloc walkers. This is missing the page table modification > tracking, and the ability to synchronize the PTE updates afterwards. > Provide flush_vm_area() for the users of alloc_vm_area() that assumes > the worst and ensures that the page directories are correctly flushed > upon construction. > > The impact is most pronounced on x86_32 due to the delayed set_pmd(). > > Reported-by: Pavel Machek <pavel@ucw.cz> > References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") > References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()") > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Joerg Roedel <jroedel@suse.de> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Dave Airlie <airlied@redhat.com> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Cc: Pavel Machek <pavel@ucw.cz> > Cc: David Vrabel <david.vrabel@citrix.com> > Cc: <stable@vger.kernel.org> # v5.8+ > --- > include/linux/vmalloc.h | 1 + > mm/vmalloc.c | 16 ++++++++++++++++ > 2 files changed, 17 insertions(+) > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index 0221f852a7e1..a253b27df0ac 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr) > > /* Allocate/destroy a 'vmalloc' VM area. */ > extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); > +extern void flush_vm_area(struct vm_struct *area); > extern void free_vm_area(struct vm_struct *area); > > /* for /dev/kmem */ > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index b482d240f9a2..c41934486031 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) > } > EXPORT_SYMBOL_GPL(alloc_vm_area); > > +void flush_vm_area(struct vm_struct *area) > +{ > + unsigned long addr = (unsigned long)area->addr; > + > + /* apply_to_page_range() doesn't track the damage, assume the worst */ > + if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED | > + PGTBL_PMD_MODIFIED | > + PGTBL_PUD_MODIFIED | > + PGTBL_P4D_MODIFIED | > + PGTBL_PGD_MODIFIED)) > + arch_sync_kernel_mappings(addr, addr + area->size); This should happen in __apply_to_page_range() directly and look like this: if (ARCH_PAGE_TABLE_SYNC_MASK && create) arch_sync_kernel_mappings(addr, addr + size); Or even better, track whether something had to be allocated in the __apply_to_page_range() path and check for: if (ARCH_PAGE_TABLE_SYNC_MASK & mask) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction @ 2020-08-21 9:51 ` Joerg Roedel 0 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 9:51 UTC (permalink / raw) To: Chris Wilson Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote: > The alloc_vm_area() is another method for drivers to > vmap/map_kernel_range that uses apply_to_page_range() rather than the > direct vmalloc walkers. This is missing the page table modification > tracking, and the ability to synchronize the PTE updates afterwards. > Provide flush_vm_area() for the users of alloc_vm_area() that assumes > the worst and ensures that the page directories are correctly flushed > upon construction. > > The impact is most pronounced on x86_32 due to the delayed set_pmd(). > > Reported-by: Pavel Machek <pavel@ucw.cz> > References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") > References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()") > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Joerg Roedel <jroedel@suse.de> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Dave Airlie <airlied@redhat.com> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Cc: Pavel Machek <pavel@ucw.cz> > Cc: David Vrabel <david.vrabel@citrix.com> > Cc: <stable@vger.kernel.org> # v5.8+ > --- > include/linux/vmalloc.h | 1 + > mm/vmalloc.c | 16 ++++++++++++++++ > 2 files changed, 17 insertions(+) > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index 0221f852a7e1..a253b27df0ac 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr) > > /* Allocate/destroy a 'vmalloc' VM area. */ > extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); > +extern void flush_vm_area(struct vm_struct *area); > extern void free_vm_area(struct vm_struct *area); > > /* for /dev/kmem */ > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index b482d240f9a2..c41934486031 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) > } > EXPORT_SYMBOL_GPL(alloc_vm_area); > > +void flush_vm_area(struct vm_struct *area) > +{ > + unsigned long addr = (unsigned long)area->addr; > + > + /* apply_to_page_range() doesn't track the damage, assume the worst */ > + if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED | > + PGTBL_PMD_MODIFIED | > + PGTBL_PUD_MODIFIED | > + PGTBL_P4D_MODIFIED | > + PGTBL_PGD_MODIFIED)) > + arch_sync_kernel_mappings(addr, addr + area->size); This should happen in __apply_to_page_range() directly and look like this: if (ARCH_PAGE_TABLE_SYNC_MASK && create) arch_sync_kernel_mappings(addr, addr + size); Or even better, track whether something had to be allocated in the __apply_to_page_range() path and check for: if (ARCH_PAGE_TABLE_SYNC_MASK & mask) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction 2020-08-21 9:51 ` [Intel-gfx] " Joerg Roedel @ 2020-08-21 9:54 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 9:54 UTC (permalink / raw) To: Joerg Roedel Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable Quoting Joerg Roedel (2020-08-21 10:51:29) > On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote: > > The alloc_vm_area() is another method for drivers to > > vmap/map_kernel_range that uses apply_to_page_range() rather than the > > direct vmalloc walkers. This is missing the page table modification > > tracking, and the ability to synchronize the PTE updates afterwards. > > Provide flush_vm_area() for the users of alloc_vm_area() that assumes > > the worst and ensures that the page directories are correctly flushed > > upon construction. > > > > The impact is most pronounced on x86_32 due to the delayed set_pmd(). > > > > Reported-by: Pavel Machek <pavel@ucw.cz> > > References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") > > References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()") > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: Joerg Roedel <jroedel@suse.de> > > Cc: Linus Torvalds <torvalds@linux-foundation.org> > > Cc: Dave Airlie <airlied@redhat.com> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Cc: Pavel Machek <pavel@ucw.cz> > > Cc: David Vrabel <david.vrabel@citrix.com> > > Cc: <stable@vger.kernel.org> # v5.8+ > > --- > > include/linux/vmalloc.h | 1 + > > mm/vmalloc.c | 16 ++++++++++++++++ > > 2 files changed, 17 insertions(+) > > > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > > index 0221f852a7e1..a253b27df0ac 100644 > > --- a/include/linux/vmalloc.h > > +++ b/include/linux/vmalloc.h > > @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr) > > > > /* Allocate/destroy a 'vmalloc' VM area. */ > > extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); > > +extern void flush_vm_area(struct vm_struct *area); > > extern void free_vm_area(struct vm_struct *area); > > > > /* for /dev/kmem */ > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index b482d240f9a2..c41934486031 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) > > } > > EXPORT_SYMBOL_GPL(alloc_vm_area); > > > > +void flush_vm_area(struct vm_struct *area) > > +{ > > + unsigned long addr = (unsigned long)area->addr; > > + > > + /* apply_to_page_range() doesn't track the damage, assume the worst */ > > + if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED | > > + PGTBL_PMD_MODIFIED | > > + PGTBL_PUD_MODIFIED | > > + PGTBL_P4D_MODIFIED | > > + PGTBL_PGD_MODIFIED)) > > + arch_sync_kernel_mappings(addr, addr + area->size); > > This should happen in __apply_to_page_range() directly and look like > this: Ok. I thought it had to be after assigning the *ptep. If we apply the sync first, do not have to worry about PGTBL_PTE_MODIFIED from the *ptep? -Chris ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction @ 2020-08-21 9:54 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 9:54 UTC (permalink / raw) To: Joerg Roedel Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds Quoting Joerg Roedel (2020-08-21 10:51:29) > On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote: > > The alloc_vm_area() is another method for drivers to > > vmap/map_kernel_range that uses apply_to_page_range() rather than the > > direct vmalloc walkers. This is missing the page table modification > > tracking, and the ability to synchronize the PTE updates afterwards. > > Provide flush_vm_area() for the users of alloc_vm_area() that assumes > > the worst and ensures that the page directories are correctly flushed > > upon construction. > > > > The impact is most pronounced on x86_32 due to the delayed set_pmd(). > > > > Reported-by: Pavel Machek <pavel@ucw.cz> > > References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") > > References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()") > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: Joerg Roedel <jroedel@suse.de> > > Cc: Linus Torvalds <torvalds@linux-foundation.org> > > Cc: Dave Airlie <airlied@redhat.com> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Cc: Pavel Machek <pavel@ucw.cz> > > Cc: David Vrabel <david.vrabel@citrix.com> > > Cc: <stable@vger.kernel.org> # v5.8+ > > --- > > include/linux/vmalloc.h | 1 + > > mm/vmalloc.c | 16 ++++++++++++++++ > > 2 files changed, 17 insertions(+) > > > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > > index 0221f852a7e1..a253b27df0ac 100644 > > --- a/include/linux/vmalloc.h > > +++ b/include/linux/vmalloc.h > > @@ -204,6 +204,7 @@ static inline void set_vm_flush_reset_perms(void *addr) > > > > /* Allocate/destroy a 'vmalloc' VM area. */ > > extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes); > > +extern void flush_vm_area(struct vm_struct *area); > > extern void free_vm_area(struct vm_struct *area); > > > > /* for /dev/kmem */ > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index b482d240f9a2..c41934486031 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -3078,6 +3078,22 @@ struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes) > > } > > EXPORT_SYMBOL_GPL(alloc_vm_area); > > > > +void flush_vm_area(struct vm_struct *area) > > +{ > > + unsigned long addr = (unsigned long)area->addr; > > + > > + /* apply_to_page_range() doesn't track the damage, assume the worst */ > > + if (ARCH_PAGE_TABLE_SYNC_MASK & (PGTBL_PTE_MODIFIED | > > + PGTBL_PMD_MODIFIED | > > + PGTBL_PUD_MODIFIED | > > + PGTBL_P4D_MODIFIED | > > + PGTBL_PGD_MODIFIED)) > > + arch_sync_kernel_mappings(addr, addr + area->size); > > This should happen in __apply_to_page_range() directly and look like > this: Ok. I thought it had to be after assigning the *ptep. If we apply the sync first, do not have to worry about PGTBL_PTE_MODIFIED from the *ptep? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction 2020-08-21 9:54 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 10:22 ` Joerg Roedel -1 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 10:22 UTC (permalink / raw) To: Chris Wilson Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable On Fri, Aug 21, 2020 at 10:54:22AM +0100, Chris Wilson wrote: > Ok. I thought it had to be after assigning the *ptep. If we apply the > sync first, do not have to worry about PGTBL_PTE_MODIFIED from the > *ptep? Hmm, if I understand the code correctly, you are re-implementing some generic ioremap/vmalloc mapping logic in the i915 driver. I don't know the reason, but if it is valid you need to manually call arch_sync_kernel_mappings() from your driver like this to be correct: if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PTE_MODIFIED) arch_sync_kernel_mappings(); In practice this is a no-op, because nobody sets PGTBL_PTE_MODIFIED in ARCH_PAGE_TABLE_SYNC_MASK, so the above code would be optimized away. But what you really care about is the tracking in apply_to_page_range(), as that allocates the !pte levels of your page-table, which needs synchronization on x86-32. Btw, what are the reasons you can't use generic vmalloc/ioremap interfaces to map the range? Regards, Joerg ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction @ 2020-08-21 10:22 ` Joerg Roedel 0 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 10:22 UTC (permalink / raw) To: Chris Wilson Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds On Fri, Aug 21, 2020 at 10:54:22AM +0100, Chris Wilson wrote: > Ok. I thought it had to be after assigning the *ptep. If we apply the > sync first, do not have to worry about PGTBL_PTE_MODIFIED from the > *ptep? Hmm, if I understand the code correctly, you are re-implementing some generic ioremap/vmalloc mapping logic in the i915 driver. I don't know the reason, but if it is valid you need to manually call arch_sync_kernel_mappings() from your driver like this to be correct: if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PTE_MODIFIED) arch_sync_kernel_mappings(); In practice this is a no-op, because nobody sets PGTBL_PTE_MODIFIED in ARCH_PAGE_TABLE_SYNC_MASK, so the above code would be optimized away. But what you really care about is the tracking in apply_to_page_range(), as that allocates the !pte levels of your page-table, which needs synchronization on x86-32. Btw, what are the reasons you can't use generic vmalloc/ioremap interfaces to map the range? Regards, Joerg _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction 2020-08-21 10:22 ` [Intel-gfx] " Joerg Roedel @ 2020-08-21 10:36 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 10:36 UTC (permalink / raw) To: Joerg Roedel Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable Quoting Joerg Roedel (2020-08-21 11:22:04) > On Fri, Aug 21, 2020 at 10:54:22AM +0100, Chris Wilson wrote: > > Ok. I thought it had to be after assigning the *ptep. If we apply the > > sync first, do not have to worry about PGTBL_PTE_MODIFIED from the > > *ptep? > > Hmm, if I understand the code correctly, you are re-implementing some > generic ioremap/vmalloc mapping logic in the i915 driver. I don't know > the reason, but if it is valid you need to manually call > arch_sync_kernel_mappings() from your driver like this to be correct: > > if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PTE_MODIFIED) > arch_sync_kernel_mappings(); > > In practice this is a no-op, because nobody sets PGTBL_PTE_MODIFIED in > ARCH_PAGE_TABLE_SYNC_MASK, so the above code would be optimized away. > > But what you really care about is the tracking in apply_to_page_range(), > as that allocates the !pte levels of your page-table, which needs > synchronization on x86-32. > > Btw, what are the reasons you can't use generic vmalloc/ioremap > interfaces to map the range? ioremap_prot and ioremap_page_range assume a contiguous IO address. So we needed to allocate the vmalloc area [and would then need to iterate over the discontiguous iomem chunks with ioremap_page_range], and since alloc_vm_area returned the ptep, it looked clearer to then assign those according to whether we wanted ioremapping or a plain page. So we ended up with one call to the core to return us a vm_struct and a pte array that worked for either backing store. -Chris ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction @ 2020-08-21 10:36 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 10:36 UTC (permalink / raw) To: Joerg Roedel Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds Quoting Joerg Roedel (2020-08-21 11:22:04) > On Fri, Aug 21, 2020 at 10:54:22AM +0100, Chris Wilson wrote: > > Ok. I thought it had to be after assigning the *ptep. If we apply the > > sync first, do not have to worry about PGTBL_PTE_MODIFIED from the > > *ptep? > > Hmm, if I understand the code correctly, you are re-implementing some > generic ioremap/vmalloc mapping logic in the i915 driver. I don't know > the reason, but if it is valid you need to manually call > arch_sync_kernel_mappings() from your driver like this to be correct: > > if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PTE_MODIFIED) > arch_sync_kernel_mappings(); > > In practice this is a no-op, because nobody sets PGTBL_PTE_MODIFIED in > ARCH_PAGE_TABLE_SYNC_MASK, so the above code would be optimized away. > > But what you really care about is the tracking in apply_to_page_range(), > as that allocates the !pte levels of your page-table, which needs > synchronization on x86-32. > > Btw, what are the reasons you can't use generic vmalloc/ioremap > interfaces to map the range? ioremap_prot and ioremap_page_range assume a contiguous IO address. So we needed to allocate the vmalloc area [and would then need to iterate over the discontiguous iomem chunks with ioremap_page_range], and since alloc_vm_area returned the ptep, it looked clearer to then assign those according to whether we wanted ioremapping or a plain page. So we ended up with one call to the core to return us a vm_struct and a pte array that worked for either backing store. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH] mm: Track page table modifications in __apply_to_page_range() construction 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 10:09 ` Joerg Roedel -1 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 10:09 UTC (permalink / raw) To: Chris Wilson Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable The __apply_to_page_range() function is also used to change and/or allocate page-table pages in the vmalloc area of the address space. Make sure these changes get synchronized to other page-tables in the system by calling arch_sync_kernel_mappings() when necessary. Signed-off-by: Joerg Roedel <jroedel@suse.de> --- (Only compile tested on x86-64 so far) mm/memory.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 3a7779d9891d..fd845991f14a 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -83,6 +83,7 @@ #include <asm/tlb.h> #include <asm/tlbflush.h> +#include "pgalloc-track.h" #include "internal.h" #if defined(LAST_CPUPID_NOT_IN_PAGE_FLAGS) && !defined(CONFIG_COMPILE_TEST) @@ -2206,7 +2207,8 @@ EXPORT_SYMBOL(vm_iomap_memory); static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pte_t *pte; int err = 0; @@ -2235,6 +2237,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, break; } } while (addr += PAGE_SIZE, addr != end); + *mask |= PGTBL_PTE_MODIFIED; arch_leave_lazy_mmu_mode(); @@ -2245,7 +2248,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pmd_t *pmd; unsigned long next; @@ -2254,7 +2258,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, BUG_ON(pud_huge(*pud)); if (create) { - pmd = pmd_alloc(mm, pud, addr); + pmd = pmd_alloc_track(mm, pud, addr, mask); if (!pmd) return -ENOMEM; } else { @@ -2264,7 +2268,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, next = pmd_addr_end(addr, end); if (create || !pmd_none_or_clear_bad(pmd)) { err = apply_to_pte_range(mm, pmd, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2274,14 +2278,15 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pud_t *pud; unsigned long next; int err = 0; if (create) { - pud = pud_alloc(mm, p4d, addr); + pud = pud_alloc_track(mm, p4d, addr, mask); if (!pud) return -ENOMEM; } else { @@ -2291,7 +2296,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, next = pud_addr_end(addr, end); if (create || !pud_none_or_clear_bad(pud)) { err = apply_to_pmd_range(mm, pud, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2301,14 +2306,15 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { p4d_t *p4d; unsigned long next; int err = 0; if (create) { - p4d = p4d_alloc(mm, pgd, addr); + p4d = p4d_alloc_track(mm, pgd, addr, mask); if (!p4d) return -ENOMEM; } else { @@ -2318,7 +2324,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, next = p4d_addr_end(addr, end); if (create || !p4d_none_or_clear_bad(p4d)) { err = apply_to_pud_range(mm, p4d, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2333,6 +2339,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, pgd_t *pgd; unsigned long next; unsigned long end = addr + size; + pgtbl_mod_mask mask = 0; int err = 0; if (WARN_ON(addr >= end)) @@ -2343,11 +2350,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, next = pgd_addr_end(addr, end); if (!create && pgd_none_or_clear_bad(pgd)) continue; - err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create); + err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create, &mask); if (err) break; } while (pgd++, addr = next, addr != end); + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) + arch_sync_kernel_mappings(addr, addr + size); + return err; } -- 2.28.0 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction @ 2020-08-21 10:09 ` Joerg Roedel 0 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 10:09 UTC (permalink / raw) To: Chris Wilson Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds The __apply_to_page_range() function is also used to change and/or allocate page-table pages in the vmalloc area of the address space. Make sure these changes get synchronized to other page-tables in the system by calling arch_sync_kernel_mappings() when necessary. Signed-off-by: Joerg Roedel <jroedel@suse.de> --- (Only compile tested on x86-64 so far) mm/memory.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 3a7779d9891d..fd845991f14a 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -83,6 +83,7 @@ #include <asm/tlb.h> #include <asm/tlbflush.h> +#include "pgalloc-track.h" #include "internal.h" #if defined(LAST_CPUPID_NOT_IN_PAGE_FLAGS) && !defined(CONFIG_COMPILE_TEST) @@ -2206,7 +2207,8 @@ EXPORT_SYMBOL(vm_iomap_memory); static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pte_t *pte; int err = 0; @@ -2235,6 +2237,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, break; } } while (addr += PAGE_SIZE, addr != end); + *mask |= PGTBL_PTE_MODIFIED; arch_leave_lazy_mmu_mode(); @@ -2245,7 +2248,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pmd_t *pmd; unsigned long next; @@ -2254,7 +2258,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, BUG_ON(pud_huge(*pud)); if (create) { - pmd = pmd_alloc(mm, pud, addr); + pmd = pmd_alloc_track(mm, pud, addr, mask); if (!pmd) return -ENOMEM; } else { @@ -2264,7 +2268,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, next = pmd_addr_end(addr, end); if (create || !pmd_none_or_clear_bad(pmd)) { err = apply_to_pte_range(mm, pmd, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2274,14 +2278,15 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { pud_t *pud; unsigned long next; int err = 0; if (create) { - pud = pud_alloc(mm, p4d, addr); + pud = pud_alloc_track(mm, p4d, addr, mask); if (!pud) return -ENOMEM; } else { @@ -2291,7 +2296,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, next = pud_addr_end(addr, end); if (create || !pud_none_or_clear_bad(pud)) { err = apply_to_pmd_range(mm, pud, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2301,14 +2306,15 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, unsigned long addr, unsigned long end, - pte_fn_t fn, void *data, bool create) + pte_fn_t fn, void *data, bool create, + pgtbl_mod_mask *mask) { p4d_t *p4d; unsigned long next; int err = 0; if (create) { - p4d = p4d_alloc(mm, pgd, addr); + p4d = p4d_alloc_track(mm, pgd, addr, mask); if (!p4d) return -ENOMEM; } else { @@ -2318,7 +2324,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, next = p4d_addr_end(addr, end); if (create || !p4d_none_or_clear_bad(p4d)) { err = apply_to_pud_range(mm, p4d, addr, next, fn, data, - create); + create, mask); if (err) break; } @@ -2333,6 +2339,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, pgd_t *pgd; unsigned long next; unsigned long end = addr + size; + pgtbl_mod_mask mask = 0; int err = 0; if (WARN_ON(addr >= end)) @@ -2343,11 +2350,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, next = pgd_addr_end(addr, end); if (!create && pgd_none_or_clear_bad(pgd)) continue; - err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create); + err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create, &mask); if (err) break; } while (pgd++, addr = next, addr != end); + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) + arch_sync_kernel_mappings(addr, addr + size); + return err; } -- 2.28.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH] mm: Track page table modifications in __apply_to_page_range() construction 2020-08-21 10:09 ` [Intel-gfx] " Joerg Roedel @ 2020-08-21 10:13 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 10:13 UTC (permalink / raw) To: Joerg Roedel Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable Quoting Joerg Roedel (2020-08-21 11:09:02) > @@ -2333,6 +2339,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, > pgd_t *pgd; > unsigned long next; > unsigned long end = addr + size; > + pgtbl_mod_mask mask = 0; > int err = 0; > > if (WARN_ON(addr >= end)) > @@ -2343,11 +2350,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, > next = pgd_addr_end(addr, end); > if (!create && pgd_none_or_clear_bad(pgd)) > continue; > - err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create); > + err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create, &mask); > if (err) > break; > } while (pgd++, addr = next, addr != end); > > + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) > + arch_sync_kernel_mappings(addr, addr + size); We need to store the initial addr, as here addr == end [or earlier on earlier], so range is (start, addr). -Chris ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction @ 2020-08-21 10:13 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 10:13 UTC (permalink / raw) To: Joerg Roedel Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds Quoting Joerg Roedel (2020-08-21 11:09:02) > @@ -2333,6 +2339,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, > pgd_t *pgd; > unsigned long next; > unsigned long end = addr + size; > + pgtbl_mod_mask mask = 0; > int err = 0; > > if (WARN_ON(addr >= end)) > @@ -2343,11 +2350,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, > next = pgd_addr_end(addr, end); > if (!create && pgd_none_or_clear_bad(pgd)) > continue; > - err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create); > + err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create, &mask); > if (err) > break; > } while (pgd++, addr = next, addr != end); > > + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) > + arch_sync_kernel_mappings(addr, addr + size); We need to store the initial addr, as here addr == end [or earlier on earlier], so range is (start, addr). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] mm: Track page table modifications in __apply_to_page_range() construction 2020-08-21 10:13 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 10:23 ` Joerg Roedel -1 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 10:23 UTC (permalink / raw) To: Chris Wilson Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote: > We need to store the initial addr, as here addr == end [or earlier on > earlier], so range is (start, addr). Right, I missed that, thanks for pointing it out. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction @ 2020-08-21 10:23 ` Joerg Roedel 0 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 10:23 UTC (permalink / raw) To: Chris Wilson Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote: > We need to store the initial addr, as here addr == end [or earlier on > earlier], so range is (start, addr). Right, I missed that, thanks for pointing it out. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] mm: Track page table modifications in __apply_to_page_range() construction 2020-08-21 10:23 ` [Intel-gfx] " Joerg Roedel @ 2020-08-21 10:39 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 10:39 UTC (permalink / raw) To: Joerg Roedel Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable Quoting Joerg Roedel (2020-08-21 11:23:43) > On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote: > > We need to store the initial addr, as here addr == end [or earlier on > > earlier], so range is (start, addr). > > Right, I missed that, thanks for pointing it out. And with that (start, addr) Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32 -Chris ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction @ 2020-08-21 10:39 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 10:39 UTC (permalink / raw) To: Joerg Roedel Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds Quoting Joerg Roedel (2020-08-21 11:23:43) > On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote: > > We need to store the initial addr, as here addr == end [or earlier on > > earlier], so range is (start, addr). > > Right, I missed that, thanks for pointing it out. And with that (start, addr) Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32 -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] mm: Track page table modifications in __apply_to_page_range() construction 2020-08-21 10:39 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 11:38 ` Chris Wilson -1 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 11:38 UTC (permalink / raw) To: Joerg Roedel Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable Quoting Chris Wilson (2020-08-21 11:39:19) > Quoting Joerg Roedel (2020-08-21 11:23:43) > > On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote: > > > We need to store the initial addr, as here addr == end [or earlier on > > > earlier], so range is (start, addr). > > > > Right, I missed that, thanks for pointing it out. > > And with that (start, addr) > > Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32 In the version I tested, I also had @@ -2216,7 +2216,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, if (create) { pte = (mm == &init_mm) ? - pte_alloc_kernel(pmd, addr) : + pte_alloc_kernel_track(pmd, addr, mask) : pte_alloc_map_lock(mm, pmd, addr, &ptl); if (!pte) return -ENOMEM; And that PGTBL_PMD_MODIFIED makes a difference. -Chris ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction @ 2020-08-21 11:38 ` Chris Wilson 0 siblings, 0 replies; 40+ messages in thread From: Chris Wilson @ 2020-08-21 11:38 UTC (permalink / raw) To: Joerg Roedel Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds Quoting Chris Wilson (2020-08-21 11:39:19) > Quoting Joerg Roedel (2020-08-21 11:23:43) > > On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote: > > > We need to store the initial addr, as here addr == end [or earlier on > > > earlier], so range is (start, addr). > > > > Right, I missed that, thanks for pointing it out. > > And with that (start, addr) > > Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32 In the version I tested, I also had @@ -2216,7 +2216,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, if (create) { pte = (mm == &init_mm) ? - pte_alloc_kernel(pmd, addr) : + pte_alloc_kernel_track(pmd, addr, mask) : pte_alloc_map_lock(mm, pmd, addr, &ptl); if (!pte) return -ENOMEM; And that PGTBL_PMD_MODIFIED makes a difference. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] mm: Track page table modifications in __apply_to_page_range() construction 2020-08-21 11:38 ` [Intel-gfx] " Chris Wilson @ 2020-08-21 12:18 ` Joerg Roedel -1 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 12:18 UTC (permalink / raw) To: Chris Wilson Cc: linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable On Fri, Aug 21, 2020 at 12:38:03PM +0100, Chris Wilson wrote: > In the version I tested, I also had > > @@ -2216,7 +2216,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > > if (create) { > pte = (mm == &init_mm) ? > - pte_alloc_kernel(pmd, addr) : > + pte_alloc_kernel_track(pmd, addr, mask) : > pte_alloc_map_lock(mm, pmd, addr, &ptl); > if (!pte) > return -ENOMEM; > > And that PGTBL_PMD_MODIFIED makes a difference. Right, thanks. Added that too. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction @ 2020-08-21 12:18 ` Joerg Roedel 0 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-08-21 12:18 UTC (permalink / raw) To: Chris Wilson Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds On Fri, Aug 21, 2020 at 12:38:03PM +0100, Chris Wilson wrote: > In the version I tested, I also had > > @@ -2216,7 +2216,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > > if (create) { > pte = (mm == &init_mm) ? > - pte_alloc_kernel(pmd, addr) : > + pte_alloc_kernel_track(pmd, addr, mask) : > pte_alloc_map_lock(mm, pmd, addr, &ptl); > if (!pte) > return -ENOMEM; > > And that PGTBL_PMD_MODIFIED makes a difference. Right, thanks. Added that too. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] mm: Track page table modifications in __apply_to_page_range() construction 2020-08-21 10:09 ` [Intel-gfx] " Joerg Roedel @ 2020-08-21 10:53 ` Greg KH -1 siblings, 0 replies; 40+ messages in thread From: Greg KH @ 2020-08-21 10:53 UTC (permalink / raw) To: Joerg Roedel Cc: Chris Wilson, linux-kernel, intel-gfx, linux-mm, Pavel Machek, Andrew Morton, Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable On Fri, Aug 21, 2020 at 12:09:02PM +0200, Joerg Roedel wrote: > The __apply_to_page_range() function is also used to change and/or > allocate page-table pages in the vmalloc area of the address space. > Make sure these changes get synchronized to other page-tables in the > system by calling arch_sync_kernel_mappings() when necessary. > > Signed-off-by: Joerg Roedel <jroedel@suse.de> > --- > (Only compile tested on x86-64 so far) > > mm/memory.c | 32 +++++++++++++++++++++----------- > 1 file changed, 21 insertions(+), 11 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 3a7779d9891d..fd845991f14a 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -83,6 +83,7 @@ > #include <asm/tlb.h> > #include <asm/tlbflush.h> > > +#include "pgalloc-track.h" > #include "internal.h" > > #if defined(LAST_CPUPID_NOT_IN_PAGE_FLAGS) && !defined(CONFIG_COMPILE_TEST) > @@ -2206,7 +2207,8 @@ EXPORT_SYMBOL(vm_iomap_memory); > > static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > unsigned long addr, unsigned long end, > - pte_fn_t fn, void *data, bool create) > + pte_fn_t fn, void *data, bool create, > + pgtbl_mod_mask *mask) > { > pte_t *pte; > int err = 0; > @@ -2235,6 +2237,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > break; > } > } while (addr += PAGE_SIZE, addr != end); > + *mask |= PGTBL_PTE_MODIFIED; > > arch_leave_lazy_mmu_mode(); > > @@ -2245,7 +2248,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > > static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, > unsigned long addr, unsigned long end, > - pte_fn_t fn, void *data, bool create) > + pte_fn_t fn, void *data, bool create, > + pgtbl_mod_mask *mask) > { > pmd_t *pmd; > unsigned long next; > @@ -2254,7 +2258,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, > BUG_ON(pud_huge(*pud)); > > if (create) { > - pmd = pmd_alloc(mm, pud, addr); > + pmd = pmd_alloc_track(mm, pud, addr, mask); > if (!pmd) > return -ENOMEM; > } else { > @@ -2264,7 +2268,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, > next = pmd_addr_end(addr, end); > if (create || !pmd_none_or_clear_bad(pmd)) { > err = apply_to_pte_range(mm, pmd, addr, next, fn, data, > - create); > + create, mask); > if (err) > break; > } > @@ -2274,14 +2278,15 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, > > static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, > unsigned long addr, unsigned long end, > - pte_fn_t fn, void *data, bool create) > + pte_fn_t fn, void *data, bool create, > + pgtbl_mod_mask *mask) > { > pud_t *pud; > unsigned long next; > int err = 0; > > if (create) { > - pud = pud_alloc(mm, p4d, addr); > + pud = pud_alloc_track(mm, p4d, addr, mask); > if (!pud) > return -ENOMEM; > } else { > @@ -2291,7 +2296,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, > next = pud_addr_end(addr, end); > if (create || !pud_none_or_clear_bad(pud)) { > err = apply_to_pmd_range(mm, pud, addr, next, fn, data, > - create); > + create, mask); > if (err) > break; > } > @@ -2301,14 +2306,15 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, > > static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, > unsigned long addr, unsigned long end, > - pte_fn_t fn, void *data, bool create) > + pte_fn_t fn, void *data, bool create, > + pgtbl_mod_mask *mask) > { > p4d_t *p4d; > unsigned long next; > int err = 0; > > if (create) { > - p4d = p4d_alloc(mm, pgd, addr); > + p4d = p4d_alloc_track(mm, pgd, addr, mask); > if (!p4d) > return -ENOMEM; > } else { > @@ -2318,7 +2324,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, > next = p4d_addr_end(addr, end); > if (create || !p4d_none_or_clear_bad(p4d)) { > err = apply_to_pud_range(mm, p4d, addr, next, fn, data, > - create); > + create, mask); > if (err) > break; > } > @@ -2333,6 +2339,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, > pgd_t *pgd; > unsigned long next; > unsigned long end = addr + size; > + pgtbl_mod_mask mask = 0; > int err = 0; > > if (WARN_ON(addr >= end)) > @@ -2343,11 +2350,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, > next = pgd_addr_end(addr, end); > if (!create && pgd_none_or_clear_bad(pgd)) > continue; > - err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create); > + err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create, &mask); > if (err) > break; > } while (pgd++, addr = next, addr != end); > > + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) > + arch_sync_kernel_mappings(addr, addr + size); > + > return err; > } > > -- > 2.28.0 > <formletter> This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. </formletter> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [Intel-gfx] [PATCH] mm: Track page table modifications in __apply_to_page_range() construction @ 2020-08-21 10:53 ` Greg KH 0 siblings, 0 replies; 40+ messages in thread From: Greg KH @ 2020-08-21 10:53 UTC (permalink / raw) To: Joerg Roedel Cc: intel-gfx, linux-kernel, stable, Chris Wilson, linux-mm, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds On Fri, Aug 21, 2020 at 12:09:02PM +0200, Joerg Roedel wrote: > The __apply_to_page_range() function is also used to change and/or > allocate page-table pages in the vmalloc area of the address space. > Make sure these changes get synchronized to other page-tables in the > system by calling arch_sync_kernel_mappings() when necessary. > > Signed-off-by: Joerg Roedel <jroedel@suse.de> > --- > (Only compile tested on x86-64 so far) > > mm/memory.c | 32 +++++++++++++++++++++----------- > 1 file changed, 21 insertions(+), 11 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 3a7779d9891d..fd845991f14a 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -83,6 +83,7 @@ > #include <asm/tlb.h> > #include <asm/tlbflush.h> > > +#include "pgalloc-track.h" > #include "internal.h" > > #if defined(LAST_CPUPID_NOT_IN_PAGE_FLAGS) && !defined(CONFIG_COMPILE_TEST) > @@ -2206,7 +2207,8 @@ EXPORT_SYMBOL(vm_iomap_memory); > > static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > unsigned long addr, unsigned long end, > - pte_fn_t fn, void *data, bool create) > + pte_fn_t fn, void *data, bool create, > + pgtbl_mod_mask *mask) > { > pte_t *pte; > int err = 0; > @@ -2235,6 +2237,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > break; > } > } while (addr += PAGE_SIZE, addr != end); > + *mask |= PGTBL_PTE_MODIFIED; > > arch_leave_lazy_mmu_mode(); > > @@ -2245,7 +2248,8 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > > static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, > unsigned long addr, unsigned long end, > - pte_fn_t fn, void *data, bool create) > + pte_fn_t fn, void *data, bool create, > + pgtbl_mod_mask *mask) > { > pmd_t *pmd; > unsigned long next; > @@ -2254,7 +2258,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, > BUG_ON(pud_huge(*pud)); > > if (create) { > - pmd = pmd_alloc(mm, pud, addr); > + pmd = pmd_alloc_track(mm, pud, addr, mask); > if (!pmd) > return -ENOMEM; > } else { > @@ -2264,7 +2268,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, > next = pmd_addr_end(addr, end); > if (create || !pmd_none_or_clear_bad(pmd)) { > err = apply_to_pte_range(mm, pmd, addr, next, fn, data, > - create); > + create, mask); > if (err) > break; > } > @@ -2274,14 +2278,15 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, > > static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, > unsigned long addr, unsigned long end, > - pte_fn_t fn, void *data, bool create) > + pte_fn_t fn, void *data, bool create, > + pgtbl_mod_mask *mask) > { > pud_t *pud; > unsigned long next; > int err = 0; > > if (create) { > - pud = pud_alloc(mm, p4d, addr); > + pud = pud_alloc_track(mm, p4d, addr, mask); > if (!pud) > return -ENOMEM; > } else { > @@ -2291,7 +2296,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, > next = pud_addr_end(addr, end); > if (create || !pud_none_or_clear_bad(pud)) { > err = apply_to_pmd_range(mm, pud, addr, next, fn, data, > - create); > + create, mask); > if (err) > break; > } > @@ -2301,14 +2306,15 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, > > static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, > unsigned long addr, unsigned long end, > - pte_fn_t fn, void *data, bool create) > + pte_fn_t fn, void *data, bool create, > + pgtbl_mod_mask *mask) > { > p4d_t *p4d; > unsigned long next; > int err = 0; > > if (create) { > - p4d = p4d_alloc(mm, pgd, addr); > + p4d = p4d_alloc_track(mm, pgd, addr, mask); > if (!p4d) > return -ENOMEM; > } else { > @@ -2318,7 +2324,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, > next = p4d_addr_end(addr, end); > if (create || !p4d_none_or_clear_bad(p4d)) { > err = apply_to_pud_range(mm, p4d, addr, next, fn, data, > - create); > + create, mask); > if (err) > break; > } > @@ -2333,6 +2339,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, > pgd_t *pgd; > unsigned long next; > unsigned long end = addr + size; > + pgtbl_mod_mask mask = 0; > int err = 0; > > if (WARN_ON(addr >= end)) > @@ -2343,11 +2350,14 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, > next = pgd_addr_end(addr, end); > if (!create && pgd_none_or_clear_bad(pgd)) > continue; > - err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create); > + err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create, &mask); > if (err) > break; > } while (pgd++, addr = next, addr != end); > > + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) > + arch_sync_kernel_mappings(addr, addr + size); > + > return err; > } > > -- > 2.28.0 > <formletter> This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. </formletter> _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with mm: Track page table modifications in __apply_to_page_range() construction (rev2) 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson ` (8 preceding siblings ...) (?) @ 2020-08-21 10:27 ` Patchwork -1 siblings, 0 replies; 40+ messages in thread From: Patchwork @ 2020-08-21 10:27 UTC (permalink / raw) To: Joerg Roedel; +Cc: intel-gfx == Series Details == Series: series starting with mm: Track page table modifications in __apply_to_page_range() construction (rev2) URL : https://patchwork.freedesktop.org/series/80892/ State : failure == Summary == CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gem/i915_gem_pages.o drivers/gpu/drm/i915/gem/i915_gem_pages.c: In function ‘i915_gem_object_map’: drivers/gpu/drm/i915/gem/i915_gem_pages.c:318:2: error: implicit declaration of function ‘flush_vm_area’; did you mean ‘free_vm_area’? [-Werror=implicit-function-declaration] flush_vm_area(area); ^~~~~~~~~~~~~ free_vm_area cc1: all warnings being treated as errors scripts/Makefile.build:283: recipe for target 'drivers/gpu/drm/i915/gem/i915_gem_pages.o' failed make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_pages.o] Error 1 scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1789: recipe for target 'drivers' failed make: *** [drivers] Error 2 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson ` (9 preceding siblings ...) (?) @ 2020-08-21 11:33 ` Patchwork -1 siblings, 0 replies; 40+ messages in thread From: Patchwork @ 2020-08-21 11:33 UTC (permalink / raw) To: Joerg Roedel; +Cc: intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 13527 bytes --] == Series Details == Series: series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction URL : https://patchwork.freedesktop.org/series/80892/ State : success == Summary == CI Bug Log - changes from CI_DRM_8911_full -> Patchwork_18386_full ==================================================== Summary ------- **SUCCESS** No regressions found. Known issues ------------ Here are the changes found in Patchwork_18386_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_exec_suspend@basic-s3: - shard-snb: [PASS][1] -> [TIMEOUT][2] ([i915#1958]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-snb2/igt@gem_exec_suspend@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-snb4/igt@gem_exec_suspend@basic-s3.html * igt@gem_exec_whisper@basic-fds-forked-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-glk4/igt@gem_exec_whisper@basic-fds-forked-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-glk7/igt@gem_exec_whisper@basic-fds-forked-all.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][5] -> [DMESG-FAIL][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-glk3/igt@kms_big_fb@x-tiled-64bpp-rotate-180.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-glk8/igt@kms_big_fb@x-tiled-64bpp-rotate-180.html * igt@kms_flip@flip-vs-fences@a-edp1: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +13 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-skl8/igt@kms_flip@flip-vs-fences@a-edp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-skl5/igt@kms_flip@flip-vs-fences@a-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-kbl2/igt@kms_flip@flip-vs-suspend@c-dp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-kbl7/igt@kms_flip@flip-vs-suspend@c-dp1.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][11] -> [INCOMPLETE][12] ([i915#155]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-kbl4/igt@kms_frontbuffer_tracking@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-tglb5/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-skl1/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][17] -> [DMESG-FAIL][18] ([fdo#108145] / [i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html * igt@kms_plane_cursor@pipe-a-primary-size-128: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-glk9/igt@kms_plane_cursor@pipe-a-primary-size-128.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-glk2/igt@kms_plane_cursor@pipe-a-primary-size-128.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-iclb2/igt@kms_psr2_su@frontbuffer.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-iclb5/igt@kms_psr2_su@frontbuffer.html * igt@perf@blocking-parameterized: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#1542]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-iclb2/igt@perf@blocking-parameterized.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-iclb2/igt@perf@blocking-parameterized.html #### Possible fixes #### * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [DMESG-WARN][25] ([i915#118] / [i915#95]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-glk5/igt@gem_exec_whisper@basic-contexts-forked.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-glk4/igt@gem_exec_whisper@basic-contexts-forked.html * igt@i915_module_load@reload: - shard-skl: [DMESG-WARN][27] ([i915#1982]) -> [PASS][28] +12 similar issues [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-skl3/igt@i915_module_load@reload.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-skl10/igt@i915_module_load@reload.html * igt@i915_query@query-topology-coherent-slice-mask: - shard-iclb: [DMESG-WARN][29] ([i915#1982]) -> [PASS][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-iclb7/igt@i915_query@query-topology-coherent-slice-mask.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-iclb3/igt@i915_query@query-topology-coherent-slice-mask.html * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - shard-tglb: [DMESG-WARN][31] ([i915#1982]) -> [PASS][32] +5 similar issues [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-tglb5/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-tglb1/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-untiled: - shard-skl: [FAIL][33] ([i915#52] / [i915#54]) -> [PASS][34] [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-skl1/igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-untiled.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-skl1/igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-untiled.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-vga1-hdmi-a1: - shard-hsw: [DMESG-WARN][35] ([i915#1982]) -> [PASS][36] [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-hsw6/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-vga1-hdmi-a1.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-hsw1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-vga1-hdmi-a1.html * igt@kms_flip@2x-wf_vblank-ts-check-interruptible@ab-hdmi-a1-hdmi-a2: - shard-glk: [DMESG-WARN][37] ([i915#1982]) -> [PASS][38] [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-glk6/igt@kms_flip@2x-wf_vblank-ts-check-interruptible@ab-hdmi-a1-hdmi-a2.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-glk5/igt@kms_flip@2x-wf_vblank-ts-check-interruptible@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@plain-flip-fb-recreate@a-edp1: - shard-skl: [FAIL][39] ([i915#2122]) -> [PASS][40] [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-skl3/igt@kms_flip@plain-flip-fb-recreate@a-edp1.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-skl3/igt@kms_flip@plain-flip-fb-recreate@a-edp1.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [DMESG-WARN][41] ([i915#180]) -> [PASS][42] +3 similar issues [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-kbl7/igt@kms_hdr@bpc-switch-suspend.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-kbl2/igt@kms_hdr@bpc-switch-suspend.html - shard-skl: [FAIL][43] ([i915#1188]) -> [PASS][44] [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-skl5/igt@kms_hdr@bpc-switch-suspend.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-skl7/igt@kms_hdr@bpc-switch-suspend.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [SKIP][45] ([fdo#109441]) -> [PASS][46] +3 similar issues [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-iclb5/igt@kms_psr@psr2_sprite_plane_move.html [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html * igt@perf_pmu@module-unload: - shard-apl: [DMESG-WARN][47] ([i915#1635] / [i915#1982]) -> [PASS][48] [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-apl4/igt@perf_pmu@module-unload.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-apl2/igt@perf_pmu@module-unload.html * igt@prime_busy@after@vecs0: - shard-hsw: [FAIL][49] ([i915#2258]) -> [PASS][50] +1 similar issue [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-hsw1/igt@prime_busy@after@vecs0.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-hsw4/igt@prime_busy@after@vecs0.html #### Warnings #### * igt@gem_exec_reloc@basic-concurrent16: - shard-snb: [FAIL][51] ([i915#1930]) -> [TIMEOUT][52] ([i915#1958]) [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-snb2/igt@gem_exec_reloc@basic-concurrent16.html [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-snb4/igt@gem_exec_reloc@basic-concurrent16.html - shard-glk: [TIMEOUT][53] ([i915#1958]) -> [INCOMPLETE][54] ([i915#1958]) [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-glk8/igt@gem_exec_reloc@basic-concurrent16.html [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-glk3/igt@gem_exec_reloc@basic-concurrent16.html * igt@gem_exec_schedule@preemptive-hang: - shard-snb: [SKIP][55] ([fdo#109271]) -> [TIMEOUT][56] ([i915#1958]) +1 similar issue [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-snb2/igt@gem_exec_schedule@preemptive-hang.html [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-snb4/igt@gem_exec_schedule@preemptive-hang.html * igt@kms_content_protection@lic: - shard-kbl: [TIMEOUT][57] ([i915#1319]) -> [TIMEOUT][58] ([i915#1319] / [i915#1958]) [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8911/shard-kbl1/igt@kms_content_protection@lic.html [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/shard-kbl4/igt@kms_content_protection@lic.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441 [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642 [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068 [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118 [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188 [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319 [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542 [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155 [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635 [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180 [i915#1930]: https://gitlab.freedesktop.org/drm/intel/issues/1930 [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122 [i915#2258]: https://gitlab.freedesktop.org/drm/intel/issues/2258 [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265 [i915#52]: https://gitlab.freedesktop.org/drm/intel/issues/52 [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (12 -> 11) ------------------------------ Missing (1): pig-snb-2600 Build changes ------------- * Linux: CI_DRM_8911 -> Patchwork_18386 CI-20190529: 20190529 CI_DRM_8911: a1029718e0c12c304c20384a838b02c95f6262d5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5769: 4e5f76be680b65780204668e302026cf638decc9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18386: 9e1d77a3e2faac6f5624fe505f2af1b80357ebf3 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18386/index.html [-- Attachment #1.2: Type: text/html, Size: 16225 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2020-08-21 13:02 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-21 8:50 [PATCH 1/4] mm: Export flush_vm_area() to sync the PTEs upon construction Chris Wilson 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson 2020-08-21 8:50 ` [PATCH 2/4] drm/i915/gem: Sync the vmap " Chris Wilson 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson 2020-08-21 12:41 ` Linus Torvalds 2020-08-21 12:41 ` [Intel-gfx] " Linus Torvalds 2020-08-21 12:41 ` Linus Torvalds 2020-08-21 13:01 ` Chris Wilson 2020-08-21 13:01 ` [Intel-gfx] " Chris Wilson 2020-08-21 8:50 ` [PATCH 3/4] drm/i915/gem: Use set_pte_at() for assigning the vmapped PTE Chris Wilson 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson 2020-08-21 8:50 ` [PATCH 4/4] drm/i915/gem: Replace reloc chain with terminator on error unwind Chris Wilson 2020-08-21 8:50 ` [Intel-gfx] " Chris Wilson 2020-08-21 9:14 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction Patchwork 2020-08-21 9:16 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2020-08-21 9:29 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2020-08-21 9:51 ` [PATCH 1/4] " Joerg Roedel 2020-08-21 9:51 ` [Intel-gfx] " Joerg Roedel 2020-08-21 9:54 ` Chris Wilson 2020-08-21 9:54 ` [Intel-gfx] " Chris Wilson 2020-08-21 10:22 ` Joerg Roedel 2020-08-21 10:22 ` [Intel-gfx] " Joerg Roedel 2020-08-21 10:36 ` Chris Wilson 2020-08-21 10:36 ` [Intel-gfx] " Chris Wilson 2020-08-21 10:09 ` [PATCH] mm: Track page table modifications in __apply_to_page_range() construction Joerg Roedel 2020-08-21 10:09 ` [Intel-gfx] " Joerg Roedel 2020-08-21 10:13 ` Chris Wilson 2020-08-21 10:13 ` [Intel-gfx] " Chris Wilson 2020-08-21 10:23 ` Joerg Roedel 2020-08-21 10:23 ` [Intel-gfx] " Joerg Roedel 2020-08-21 10:39 ` Chris Wilson 2020-08-21 10:39 ` [Intel-gfx] " Chris Wilson 2020-08-21 11:38 ` Chris Wilson 2020-08-21 11:38 ` [Intel-gfx] " Chris Wilson 2020-08-21 12:18 ` Joerg Roedel 2020-08-21 12:18 ` [Intel-gfx] " Joerg Roedel 2020-08-21 10:53 ` Greg KH 2020-08-21 10:53 ` [Intel-gfx] " Greg KH 2020-08-21 10:27 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with mm: Track page table modifications in __apply_to_page_range() construction (rev2) Patchwork 2020-08-21 11:33 ` [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs upon construction Patchwork
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.