From 4caf017ee93703ba1c4504f3d73b50e6bbd4249e Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue, 15 Sep 2020 10:14:15 +0100
Subject: drm/i915/gem: Avoid implicit vmap for highmem on x86-32
Git-commit: 4caf017ee93703ba1c4504f3d73b50e6bbd4249e
Patch-mainline: v5.10-rc1
No-fix: 060bb115c2d664f04db9c7613a104dfaef3fdd98
References: bsc#1152489
On 32b, highmem using a finite set of indirect PTE (i.e. vmap) to provide
virtual mappings of the high pages. As these are finite, map_new_virtual()
must wait for some other kmap() to finish when it runs out. If we map a
large number of objects, there is no method for it to tell us to release
the mappings, and we deadlock.
However, if we make an explicit vmap of the page, that uses a larger
vmalloc arena, and also has the ability to tell us to release unwanted
mappings. Most importantly, it will fail and propagate an error instead
of waiting forever.
Fixes: fb8621d3bee8 ("drm/i915: Avoid allocating a vmap arena for a single page") #x86-32
__References: e87666b52f00 ("drm/i915/shrinker: Hook up vmap allocation failure notifier")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v4.7+
Link: https://patchwork.freedesktop.org/patch/msgid/20200915091417.4086-1-chris@chris-wilson.co.uk
(cherry picked from commit 060bb115c2d664f04db9c7613a104dfaef3fdd98)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
---
A message from ksd-import-patch:
Hello dear friend,
I'm ksd-import-patch, the tool that imported this patch
file.
I had to prefix at least one line in the commit message
with __ to work around a bug in the commit hook of
kernel-sources, which thinks the line contains a patch
tag.
If you think the patch should have been merged as it is
in upstream, please send this file via email to
kernel-cvs@suse.de
and request the problem to be fixed.
Yours truely,
ksd-import-patch
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -238,8 +238,30 @@ static void *i915_gem_object_map(const s
void *addr;
/* A single page can always be kmapped */
- if (n_pages == 1 && type == I915_MAP_WB)
- return kmap(sg_page(sgt->sgl));
+ if (n_pages == 1 && type == I915_MAP_WB) {
+ struct page *page = sg_page(sgt->sgl);
+
+ /*
+ * On 32b, highmem using a finite set of indirect PTE (i.e.
+ * vmap) to provide virtual mappings of the high pages.
+ * As these are finite, map_new_virtual() must wait for some
+ * other kmap() to finish when it runs out. If we map a large
+ * number of objects, there is no method for it to tell us
+ * to release the mappings, and we deadlock.
+ *
+ * However, if we make an explicit vmap of the page, that
+ * uses a larger vmalloc arena, and also has the ability
+ * to tell us to release unwanted mappings. Most importantly,
+ * it will fail and propagate an error instead of waiting
+ * forever.
+ *
+ * So if the page is beyond the 32b boundary, make an explicit
+ * vmap. On 64b, this check will be optimised away as we can
+ * directly kmap any page on the system.
+ */
+ if (!PageHighMem(page))
+ return kmap(page);
+ }
if (n_pages > ARRAY_SIZE(stack_pages)) {
/* Too big for stack -- allocate temporary array instead */