* [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 12:37 ` Joerg Roedel
0 siblings, 0 replies; 29+ messages in thread
From: Joerg Roedel @ 2020-08-21 12:37 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-kernel, Chris Wilson, intel-gfx, Pavel Machek,
Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi,
David Vrabel, Joerg Roedel, stable
From: Joerg Roedel <jroedel@suse.de>
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.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
Cc: <stable@vger.kernel.org> # v5.8+
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
mm/memory.c | 36 +++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 3a7779d9891d..1b7d846f6992 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;
@@ -2214,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;
@@ -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;
}
@@ -2331,8 +2337,9 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
void *data, bool create)
{
pgd_t *pgd;
- unsigned long next;
+ unsigned long start = addr, 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(start, start + size);
+
return err;
}
--
2.28.0
^ permalink raw reply related [flat|nested] 29+ messages in thread
* [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 12:37 ` Joerg Roedel
0 siblings, 0 replies; 29+ messages in thread
From: Joerg Roedel @ 2020-08-21 12:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, Chris Wilson,
linux-mm, David Vrabel, Pavel Machek, Dave Airlie,
Linus Torvalds
From: Joerg Roedel <jroedel@suse.de>
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.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
Cc: <stable@vger.kernel.org> # v5.8+
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
mm/memory.c | 36 +++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 3a7779d9891d..1b7d846f6992 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;
@@ -2214,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;
@@ -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;
}
@@ -2331,8 +2337,9 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr,
void *data, bool create)
{
pgd_t *pgd;
- unsigned long next;
+ unsigned long start = addr, 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(start, start + 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] 29+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for mm: Track page table modifications in __apply_to_page_range()
2020-08-21 12:37 ` [Intel-gfx] " Joerg Roedel
(?)
@ 2020-08-21 13:30 ` Patchwork
-1 siblings, 0 replies; 29+ messages in thread
From: Patchwork @ 2020-08-21 13:30 UTC (permalink / raw)
To: Joerg Roedel; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 3975 bytes --]
== Series Details ==
Series: mm: Track page table modifications in __apply_to_page_range()
URL : https://patchwork.freedesktop.org/series/80896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8913 -> Patchwork_18388
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/index.html
Known issues
------------
Here are the changes found in Patchwork_18388 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/fi-bsw-n3050/igt@i915_pm_rpm@basic-pci-d3-state.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/fi-bsw-n3050/igt@i915_pm_rpm@basic-pci-d3-state.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2203])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/fi-kbl-7500u/igt@kms_chamelium@common-hpd-after-suspend.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/fi-kbl-7500u/igt@kms_chamelium@common-hpd-after-suspend.html
#### Possible fixes ####
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][5] ([i915#2203]) -> [PASS][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2.html
#### Warnings ####
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][7] ([i915#62] / [i915#95]) -> [DMESG-FAIL][8] ([i915#62])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) -> [DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/fi-kbl-x1275/igt@kms_force_connector_basic@force-edid.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/fi-kbl-x1275/igt@kms_force_connector_basic@force-edid.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) +3 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/fi-kbl-x1275/igt@prime_vgem@basic-fence-flip.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/fi-kbl-x1275/igt@prime_vgem@basic-fence-flip.html
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[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_8913 -> Patchwork_18388
CI-20190529: 20190529
CI_DRM_8913: e18d8e120e73feaf39d84afe14f9a7f58b696785 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5770: f1d0c240ea2e631dfb9f493f37f8fb61cb2b1cf2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18388: 55f8f3ceea96ca4a7b7578668aa4f239898e02f8 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
55f8f3ceea96 mm: Track page table modifications in __apply_to_page_range()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/index.html
[-- Attachment #1.2: Type: text/html, Size: 5422 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] 29+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for mm: Track page table modifications in __apply_to_page_range()
2020-08-21 12:37 ` [Intel-gfx] " Joerg Roedel
(?)
(?)
@ 2020-08-21 16:39 ` Patchwork
-1 siblings, 0 replies; 29+ messages in thread
From: Patchwork @ 2020-08-21 16:39 UTC (permalink / raw)
To: Joerg Roedel; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 16773 bytes --]
== Series Details ==
Series: mm: Track page table modifications in __apply_to_page_range()
URL : https://patchwork.freedesktop.org/series/80896/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8913_full -> Patchwork_18388_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_18388_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18388_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_18388_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-hsw8/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-hsw1/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html
### Piglit changes ###
#### Possible regressions ####
* spec@glsl-1.50@execution@built-in-functions@gs-op-rshift-ivec2-int (NEW):
- pig-snb-2600: NOTRUN -> [FAIL][3] +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/pig-snb-2600/spec@glsl-1.50@execution@built-in-functions@gs-op-rshift-ivec2-int.html
New tests
---------
New tests have been introduced between CI_DRM_8913_full and Patchwork_18388_full:
### New Piglit tests (2) ###
* spec@glsl-1.50@execution@built-in-functions@gs-op-eq-bvec4-bvec4-using-if:
- Statuses : 1 fail(s)
- Exec time: [0.14] s
* spec@glsl-1.50@execution@built-in-functions@gs-op-rshift-ivec2-int:
- Statuses : 1 fail(s)
- Exec time: [0.12] s
Known issues
------------
Here are the changes found in Patchwork_18388_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_whisper@basic-forked:
- shard-glk: [PASS][4] -> [DMESG-WARN][5] ([i915#118] / [i915#95])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-glk1/igt@gem_exec_whisper@basic-forked.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-glk5/igt@gem_exec_whisper@basic-forked.html
* igt@gem_flink_basic@basic:
- shard-snb: [PASS][6] -> [TIMEOUT][7] ([i915#1958]) +3 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-snb2/igt@gem_flink_basic@basic.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-snb2/igt@gem_flink_basic@basic.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1436] / [i915#716])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-skl8/igt@gen9_exec_parse@allowed-single.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-skl6/igt@gen9_exec_parse@allowed-single.html
* igt@i915_pm_rpm@system-suspend:
- shard-kbl: [PASS][10] -> [INCOMPLETE][11] ([i915#151] / [i915#155])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-kbl1/igt@i915_pm_rpm@system-suspend.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-kbl2/igt@i915_pm_rpm@system-suspend.html
* igt@kms_color@pipe-b-ctm-negative:
- shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +6 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-skl8/igt@kms_color@pipe-b-ctm-negative.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-skl6/igt@kms_color@pipe-b-ctm-negative.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#72])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-glk2/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-glk7/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
- shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +1 similar issue
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-kbl4/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-kbl7/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
* igt@kms_flip@flip-vs-suspend@c-hdmi-a1:
- shard-hsw: [PASS][18] -> [INCOMPLETE][19] ([i915#2055])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-hsw7/igt@kms_flip@flip-vs-suspend@c-hdmi-a1.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-hsw4/igt@kms_flip@flip-vs-suspend@c-hdmi-a1.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite:
- shard-apl: [PASS][20] -> [DMESG-WARN][21] ([i915#1635] / [i915#1982]) +1 similar issue
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-apl3/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-apl1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][22] -> [FAIL][23] ([i915#1188])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-skl5/igt@kms_hdr@bpc-switch-suspend.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-skl9/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][24] -> [SKIP][25] ([fdo#109642] / [fdo#111068])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-iclb4/igt@kms_psr2_su@frontbuffer.html
* igt@kms_psr@psr2_sprite_blt:
- shard-iclb: [PASS][26] -> [SKIP][27] ([fdo#109441]) +1 similar issue
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-iclb4/igt@kms_psr@psr2_sprite_blt.html
* igt@prime_busy@hang@bcs0:
- shard-hsw: [PASS][28] -> [FAIL][29] ([i915#2258]) +4 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-hsw8/igt@prime_busy@hang@bcs0.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-hsw7/igt@prime_busy@hang@bcs0.html
#### Possible fixes ####
* igt@gem_exec_balancer@nop:
- shard-iclb: [INCOMPLETE][30] ([i915#2277]) -> [PASS][31]
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-iclb2/igt@gem_exec_balancer@nop.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-iclb3/igt@gem_exec_balancer@nop.html
* igt@gem_exec_endless@dispatch@bcs0:
- shard-tglb: [INCOMPLETE][32] -> [PASS][33]
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-tglb8/igt@gem_exec_endless@dispatch@bcs0.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-tglb1/igt@gem_exec_endless@dispatch@bcs0.html
* {igt@gem_mmap_offset@blt-coherency}:
- shard-apl: [FAIL][34] ([i915#1635]) -> [PASS][35]
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-apl4/igt@gem_mmap_offset@blt-coherency.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-apl8/igt@gem_mmap_offset@blt-coherency.html
* igt@kms_big_fb@linear-64bpp-rotate-0:
- shard-glk: [DMESG-FAIL][36] ([i915#118] / [i915#95]) -> [PASS][37]
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-glk8/igt@kms_big_fb@linear-64bpp-rotate-0.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-glk9/igt@kms_big_fb@linear-64bpp-rotate-0.html
* igt@kms_big_fb@x-tiled-8bpp-rotate-0:
- shard-apl: [DMESG-WARN][38] ([i915#1635] / [i915#1982]) -> [PASS][39] +1 similar issue
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-apl1/igt@kms_big_fb@x-tiled-8bpp-rotate-0.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-apl4/igt@kms_big_fb@x-tiled-8bpp-rotate-0.html
* igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
- shard-glk: [DMESG-WARN][40] ([i915#1982]) -> [PASS][41] +1 similar issue
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-glk3/igt@kms_cursor_legacy@cursora-vs-flipb-varying-size.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-glk4/igt@kms_cursor_legacy@cursora-vs-flipb-varying-size.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl: [FAIL][42] ([i915#2346]) -> [PASS][43]
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-skl10/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
* igt@kms_dp_aux_dev:
- shard-iclb: [DMESG-WARN][44] ([i915#2344]) -> [PASS][45]
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-iclb7/igt@kms_dp_aux_dev.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-iclb2/igt@kms_dp_aux_dev.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl: [FAIL][46] ([i915#2122]) -> [PASS][47]
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-skl5/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-skl9/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl: [DMESG-WARN][48] ([i915#180]) -> [PASS][49] +3 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-kbl4/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-kbl7/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
* igt@kms_frontbuffer_tracking@fbcpsr-suspend:
- shard-tglb: [DMESG-WARN][50] ([i915#1982]) -> [PASS][51] +1 similar issue
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-suspend.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-suspend.html
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-skl: [DMESG-WARN][52] ([i915#1982]) -> [PASS][53] +7 similar issues
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-skl1/igt@kms_plane@plane-position-covered-pipe-b-planes.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-skl6/igt@kms_plane@plane-position-covered-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [FAIL][54] ([fdo#108145] / [i915#265]) -> [PASS][55] +1 similar issue
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [SKIP][56] ([fdo#109441]) -> [PASS][57]
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-iclb5/igt@kms_psr@psr2_primary_page_flip.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_sequence@get-forked:
- shard-hsw: [INCOMPLETE][58] -> [PASS][59]
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-hsw7/igt@kms_sequence@get-forked.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-hsw4/igt@kms_sequence@get-forked.html
* igt@perf@polling-parameterized:
- shard-tglb: [FAIL][60] ([i915#1542]) -> [PASS][61]
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-tglb1/igt@perf@polling-parameterized.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-tglb1/igt@perf@polling-parameterized.html
#### Warnings ####
* igt@gem_exec_reloc@basic-concurrent16:
- shard-snb: [FAIL][62] ([i915#1930]) -> [TIMEOUT][63] ([i915#1958])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-snb2/igt@gem_exec_reloc@basic-concurrent16.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-snb2/igt@gem_exec_reloc@basic-concurrent16.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-iclb: [SKIP][64] ([i915#588]) -> [SKIP][65] ([i915#658])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-iclb2/igt@i915_pm_dc@dc3co-vpb-simulation.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-iclb4/igt@i915_pm_dc@dc3co-vpb-simulation.html
* igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen:
- shard-snb: [SKIP][66] ([fdo#109271]) -> [TIMEOUT][67] ([i915#1958]) +1 similar issue
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-snb2/igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-snb2/igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen.html
* igt@perf@polling-parameterized:
- shard-skl: [DMESG-FAIL][68] ([i915#1982]) -> [FAIL][69] ([i915#1542])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8913/shard-skl9/igt@perf@polling-parameterized.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18388/shard-skl2/igt@perf@polling-parameterized.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#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
[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#2055]: https://gitlab.freedesktop.org/drm/intel/issues/2055
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2258]: https://gitlab.freedesktop.org/drm/intel/issues/2258
[i915#2277]: https://gitlab.freedesktop.org/drm/intel/issues/2277
[i915#2344]: https://gitlab.freedesktop.org/drm/intel/issues/2344
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#588]: https://gitlab.freedesktop.org/drm/intel/issues/588
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
[i915#72]: https://gitlab.freedesktop.org/drm/intel/issues/72
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (11 -> 12)
------------------------------
Additional (1): pig-snb-2600
Build changes
-------------
* Linux: CI_DRM_8913 -> Patchwork_18388
CI-20190529: 20190529
CI_DRM_8913: e18d8e120e73feaf39d84afe14f9a7f58b696785 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5770: f1d0c240ea2e631dfb9f493f37f8fb61cb2b1cf2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18388: 55f8f3ceea96ca4a7b7578668aa4f239898e02f8 @ 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_18388/index.html
[-- Attachment #1.2: Type: text/html, Size: 19320 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] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 12:37 ` [Intel-gfx] " Joerg Roedel
@ 2020-08-21 18:51 ` Chris Wilson
-1 siblings, 0 replies; 29+ messages in thread
From: Chris Wilson @ 2020-08-21 18:51 UTC (permalink / raw)
To: Andrew Morton, Joerg Roedel
Cc: linux-mm, linux-kernel, intel-gfx, Pavel Machek, Linus Torvalds,
Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel,
Joerg Roedel, stable
Quoting Joerg Roedel (2020-08-21 13:37:46)
> From: Joerg Roedel <jroedel@suse.de>
>
> 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.
>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> Cc: <stable@vger.kernel.org> # v5.8+
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
I've doubled check that this patch by itself fixes our x86-32 vmapping
issue. Thanks,
-Chris
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 18:51 ` Chris Wilson
0 siblings, 0 replies; 29+ messages in thread
From: Chris Wilson @ 2020-08-21 18:51 UTC (permalink / raw)
To: Andrew Morton, Joerg Roedel
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, linux-mm,
David Vrabel, Pavel Machek, Dave Airlie, Linus Torvalds
Quoting Joerg Roedel (2020-08-21 13:37:46)
> From: Joerg Roedel <jroedel@suse.de>
>
> 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.
>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> Cc: <stable@vger.kernel.org> # v5.8+
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
I've doubled check that this patch by itself fixes our x86-32 vmapping
issue. Thanks,
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 12:37 ` [Intel-gfx] " Joerg Roedel
(?)
@ 2020-08-21 19:18 ` Linus Torvalds
-1 siblings, 0 replies; 29+ messages in thread
From: Linus Torvalds @ 2020-08-21 19:18 UTC (permalink / raw)
To: Joerg Roedel
Cc: Andrew Morton, Linux-MM, Linux Kernel Mailing List, Chris Wilson,
intel-gfx, Pavel Machek, Dave Airlie, Joonas Lahtinen,
Rodrigo Vivi, David Vrabel, Joerg Roedel, stable
On Fri, Aug 21, 2020 at 5:38 AM Joerg Roedel <joro@8bytes.org> wrote:
>
> From: Joerg Roedel <jroedel@suse.de>
>
> 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.
I get the strong feeling that these functions should be using a
"struct apply_details *" or something like that (the way the
zap_page_range() code has that "zap_details" thing).
Because adding more and more arguments gets pretty painful after a
while. But maybe the compiler inlining it all makes it a non-issue.
It also strikes me that I think the only architecture that uses the
whole arch_sync_kernel_mappings() thing is now just x86-32.
[ Well, x86-64 still has it, but that's because we undid the 64-bit
removal, but it's on the verge of going away and x86-64 shouldn't
actually _need_ it any more ]
So all of this seems to be purely for 32-bit x86. Which kind of makes
this all fail the smell test.
But the patch does seem to be the minimal fix for a real issue - I'm
just pointing out ugly details, not actual problems with the patch.
IOW, a somewhat reluctant Ack, hoping that this will be cleaned up
some day. Possibly/hopefully because arch_sync_kernel_mappings() just
goes away entirely.
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 19:18 ` Linus Torvalds
0 siblings, 0 replies; 29+ messages in thread
From: Linus Torvalds @ 2020-08-21 19:18 UTC (permalink / raw)
To: Joerg Roedel
Cc: Andrew Morton, Linux-MM, Linux Kernel Mailing List, Chris Wilson,
intel-gfx, Pavel Machek, Dave Airlie, Joonas Lahtinen,
Rodrigo Vivi, David Vrabel, Joerg Roedel, stable
On Fri, Aug 21, 2020 at 5:38 AM Joerg Roedel <joro@8bytes.org> wrote:
>
> From: Joerg Roedel <jroedel@suse.de>
>
> 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.
I get the strong feeling that these functions should be using a
"struct apply_details *" or something like that (the way the
zap_page_range() code has that "zap_details" thing).
Because adding more and more arguments gets pretty painful after a
while. But maybe the compiler inlining it all makes it a non-issue.
It also strikes me that I think the only architecture that uses the
whole arch_sync_kernel_mappings() thing is now just x86-32.
[ Well, x86-64 still has it, but that's because we undid the 64-bit
removal, but it's on the verge of going away and x86-64 shouldn't
actually _need_ it any more ]
So all of this seems to be purely for 32-bit x86. Which kind of makes
this all fail the smell test.
But the patch does seem to be the minimal fix for a real issue - I'm
just pointing out ugly details, not actual problems with the patch.
IOW, a somewhat reluctant Ack, hoping that this will be cleaned up
some day. Possibly/hopefully because arch_sync_kernel_mappings() just
goes away entirely.
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 19:18 ` Linus Torvalds
0 siblings, 0 replies; 29+ messages in thread
From: Linus Torvalds @ 2020-08-21 19:18 UTC (permalink / raw)
To: Joerg Roedel
Cc: Joerg Roedel, intel-gfx, Linux Kernel Mailing List, stable,
Chris Wilson, Linux-MM, David Vrabel, Pavel Machek, Dave Airlie,
Andrew Morton
On Fri, Aug 21, 2020 at 5:38 AM Joerg Roedel <joro@8bytes.org> wrote:
>
> From: Joerg Roedel <jroedel@suse.de>
>
> 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.
I get the strong feeling that these functions should be using a
"struct apply_details *" or something like that (the way the
zap_page_range() code has that "zap_details" thing).
Because adding more and more arguments gets pretty painful after a
while. But maybe the compiler inlining it all makes it a non-issue.
It also strikes me that I think the only architecture that uses the
whole arch_sync_kernel_mappings() thing is now just x86-32.
[ Well, x86-64 still has it, but that's because we undid the 64-bit
removal, but it's on the verge of going away and x86-64 shouldn't
actually _need_ it any more ]
So all of this seems to be purely for 32-bit x86. Which kind of makes
this all fail the smell test.
But the patch does seem to be the minimal fix for a real issue - I'm
just pointing out ugly details, not actual problems with the patch.
IOW, a somewhat reluctant Ack, hoping that this will be cleaned up
some day. Possibly/hopefully because arch_sync_kernel_mappings() just
goes away entirely.
Linus
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 12:37 ` [Intel-gfx] " Joerg Roedel
@ 2020-08-21 20:35 ` Andrew Morton
-1 siblings, 0 replies; 29+ messages in thread
From: Andrew Morton @ 2020-08-21 20:35 UTC (permalink / raw)
To: Joerg Roedel
Cc: linux-mm, linux-kernel, Chris Wilson, intel-gfx, Pavel Machek,
Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi,
David Vrabel, Joerg Roedel, stable
On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
There's no description here of the user-visible effects of the bug.
Please always provide this, especially when proposing a -stable
backport. Take pity upon all the downstream kernel maintainers who are
staring at this wondering whether they should risk adding it to their
kernels.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 20:35 ` Andrew Morton
0 siblings, 0 replies; 29+ messages in thread
From: Andrew Morton @ 2020-08-21 20:35 UTC (permalink / raw)
To: Joerg Roedel
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, Chris Wilson,
linux-mm, David Vrabel, Pavel Machek, Dave Airlie,
Linus Torvalds
On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
There's no description here of the user-visible effects of the bug.
Please always provide this, especially when proposing a -stable
backport. Take pity upon all the downstream kernel maintainers who are
staring at this wondering whether they should risk adding it to their
kernels.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 20:35 ` [Intel-gfx] " Andrew Morton
@ 2020-08-21 20:50 ` Chris Wilson
-1 siblings, 0 replies; 29+ messages in thread
From: Chris Wilson @ 2020-08-21 20:50 UTC (permalink / raw)
To: Andrew Morton, Joerg Roedel
Cc: linux-mm, linux-kernel, intel-gfx, Pavel Machek, Linus Torvalds,
Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel,
Joerg Roedel, stable
Quoting Andrew Morton (2020-08-21 21:35:48)
> On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
>
> There's no description here of the user-visible effects of the bug.
> Please always provide this, especially when proposing a -stable
> backport. Take pity upon all the downstream kernel maintainers who are
> staring at this wondering whether they should risk adding it to their
> kernels.
The impact appears limited to x86-32, where apply_to_page_range may miss
updating the PMD. That leads to explosions in drivers like
[ 24.227844] BUG: unable to handle page fault for address: fe036000
[ 24.228076] #PF: supervisor write access in kernel mode
[ 24.228294] #PF: error_code(0x0002) - not-present page
[ 24.228494] *pde = 00000000
[ 24.228640] Oops: 0002 [#1] SMP
[ 24.228788] CPU: 3 PID: 1300 Comm: gem_concurrent_ Not tainted 5.9.0-rc1+ #16
[ 24.228957] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 24.229297] EIP: __execlists_context_alloc+0x132/0x2d0 [i915]
[ 24.229462] Code: 31 d2 89 f0 e8 2f 55 02 00 89 45 e8 3d 00 f0 ff ff 0f 87 11 01 00 00 8b 4d e8 03 4b 30 b8 5a 5a 5a 5a ba 01 00 00 00 8d 79 04 <c7> 01 5a 5a 5a 5a c7 81 fc 0f 00 00 5a 5a 5a 5a 83 e7 fc 29 f9 81
[ 24.229759] EAX: 5a5a5a5a EBX: f60ca000 ECX: fe036000 EDX: 00000001
[ 24.229915] ESI: f43b7340 EDI: fe036004 EBP: f6389cb8 ESP: f6389c9c
[ 24.230072] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010286
[ 24.230229] CR0: 80050033 CR2: fe036000 CR3: 2d361000 CR4: 001506d0
[ 24.230385] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 24.230539] DR6: fffe0ff0 DR7: 00000400
[ 24.230675] Call Trace:
[ 24.230957] execlists_context_alloc+0x10/0x20 [i915]
[ 24.231266] intel_context_alloc_state+0x3f/0x70 [i915]
[ 24.231547] __intel_context_do_pin+0x117/0x170 [i915]
[ 24.231850] i915_gem_do_execbuffer+0xcc7/0x2500 [i915]
[ 24.232024] ? __kmalloc_track_caller+0x54/0x230
[ 24.232181] ? ktime_get+0x3e/0x120
[ 24.232333] ? dma_fence_signal+0x34/0x50
[ 24.232617] i915_gem_execbuffer2_ioctl+0xcd/0x1f0 [i915]
[ 24.232912] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
[ 24.233084] drm_ioctl_kernel+0x8f/0xd0
[ 24.233236] drm_ioctl+0x223/0x3d0
[ 24.233505] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
[ 24.233684] ? pick_next_task_fair+0x1b5/0x3d0
[ 24.233873] ? __switch_to_asm+0x36/0x50
[ 24.234021] ? drm_ioctl_kernel+0xd0/0xd0
[ 24.234167] __ia32_sys_ioctl+0x1ab/0x760
[ 24.234313] ? exit_to_user_mode_prepare+0xe5/0x110
[ 24.234453] ? syscall_exit_to_user_mode+0x23/0x130
[ 24.234601] __do_fast_syscall_32+0x3f/0x70
[ 24.234744] do_fast_syscall_32+0x29/0x60
[ 24.234885] do_SYSENTER_32+0x15/0x20
[ 24.235021] entry_SYSENTER_32+0x9f/0xf2
[ 24.235157] EIP: 0xb7f28559
[ 24.235288] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
[ 24.235576] EAX: ffffffda EBX: 00000005 ECX: c0406469 EDX: bf95556c
[ 24.235722] ESI: b7e68000 EDI: c0406469 EBP: 00000005 ESP: bf9554d8
[ 24.235869] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296
[ 24.236018] Modules linked in: i915 x86_pkg_temp_thermal intel_powerclamp crc32_pclmul crc32c_intel intel_cstate intel_uncore intel_gtt drm_kms_helper intel_pch_thermal video button autofs4 i2c_i801 i2c_smbus fan
[ 24.236336] CR2: 00000000fe036000
It looks like kasan, xen and i915 are vulnerable.
-Chris
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 20:50 ` Chris Wilson
0 siblings, 0 replies; 29+ messages in thread
From: Chris Wilson @ 2020-08-21 20:50 UTC (permalink / raw)
To: Andrew Morton, Joerg Roedel
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, linux-mm,
David Vrabel, Pavel Machek, Dave Airlie, Linus Torvalds
Quoting Andrew Morton (2020-08-21 21:35:48)
> On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
>
> There's no description here of the user-visible effects of the bug.
> Please always provide this, especially when proposing a -stable
> backport. Take pity upon all the downstream kernel maintainers who are
> staring at this wondering whether they should risk adding it to their
> kernels.
The impact appears limited to x86-32, where apply_to_page_range may miss
updating the PMD. That leads to explosions in drivers like
[ 24.227844] BUG: unable to handle page fault for address: fe036000
[ 24.228076] #PF: supervisor write access in kernel mode
[ 24.228294] #PF: error_code(0x0002) - not-present page
[ 24.228494] *pde = 00000000
[ 24.228640] Oops: 0002 [#1] SMP
[ 24.228788] CPU: 3 PID: 1300 Comm: gem_concurrent_ Not tainted 5.9.0-rc1+ #16
[ 24.228957] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 24.229297] EIP: __execlists_context_alloc+0x132/0x2d0 [i915]
[ 24.229462] Code: 31 d2 89 f0 e8 2f 55 02 00 89 45 e8 3d 00 f0 ff ff 0f 87 11 01 00 00 8b 4d e8 03 4b 30 b8 5a 5a 5a 5a ba 01 00 00 00 8d 79 04 <c7> 01 5a 5a 5a 5a c7 81 fc 0f 00 00 5a 5a 5a 5a 83 e7 fc 29 f9 81
[ 24.229759] EAX: 5a5a5a5a EBX: f60ca000 ECX: fe036000 EDX: 00000001
[ 24.229915] ESI: f43b7340 EDI: fe036004 EBP: f6389cb8 ESP: f6389c9c
[ 24.230072] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010286
[ 24.230229] CR0: 80050033 CR2: fe036000 CR3: 2d361000 CR4: 001506d0
[ 24.230385] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 24.230539] DR6: fffe0ff0 DR7: 00000400
[ 24.230675] Call Trace:
[ 24.230957] execlists_context_alloc+0x10/0x20 [i915]
[ 24.231266] intel_context_alloc_state+0x3f/0x70 [i915]
[ 24.231547] __intel_context_do_pin+0x117/0x170 [i915]
[ 24.231850] i915_gem_do_execbuffer+0xcc7/0x2500 [i915]
[ 24.232024] ? __kmalloc_track_caller+0x54/0x230
[ 24.232181] ? ktime_get+0x3e/0x120
[ 24.232333] ? dma_fence_signal+0x34/0x50
[ 24.232617] i915_gem_execbuffer2_ioctl+0xcd/0x1f0 [i915]
[ 24.232912] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
[ 24.233084] drm_ioctl_kernel+0x8f/0xd0
[ 24.233236] drm_ioctl+0x223/0x3d0
[ 24.233505] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
[ 24.233684] ? pick_next_task_fair+0x1b5/0x3d0
[ 24.233873] ? __switch_to_asm+0x36/0x50
[ 24.234021] ? drm_ioctl_kernel+0xd0/0xd0
[ 24.234167] __ia32_sys_ioctl+0x1ab/0x760
[ 24.234313] ? exit_to_user_mode_prepare+0xe5/0x110
[ 24.234453] ? syscall_exit_to_user_mode+0x23/0x130
[ 24.234601] __do_fast_syscall_32+0x3f/0x70
[ 24.234744] do_fast_syscall_32+0x29/0x60
[ 24.234885] do_SYSENTER_32+0x15/0x20
[ 24.235021] entry_SYSENTER_32+0x9f/0xf2
[ 24.235157] EIP: 0xb7f28559
[ 24.235288] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
[ 24.235576] EAX: ffffffda EBX: 00000005 ECX: c0406469 EDX: bf95556c
[ 24.235722] ESI: b7e68000 EDI: c0406469 EBP: 00000005 ESP: bf9554d8
[ 24.235869] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296
[ 24.236018] Modules linked in: i915 x86_pkg_temp_thermal intel_powerclamp crc32_pclmul crc32c_intel intel_cstate intel_uncore intel_gtt drm_kms_helper intel_pch_thermal video button autofs4 i2c_i801 i2c_smbus fan
[ 24.236336] CR2: 00000000fe036000
It looks like kasan, xen and i915 are vulnerable.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 20:50 ` [Intel-gfx] " Chris Wilson
@ 2020-08-21 21:29 ` Pavel Machek
-1 siblings, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-08-21 21:29 UTC (permalink / raw)
To: Chris Wilson
Cc: Andrew Morton, Joerg Roedel, linux-mm, linux-kernel, intel-gfx,
Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi,
David Vrabel, Joerg Roedel, stable
[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]
Hi!
> > > 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.
> >
> > There's no description here of the user-visible effects of the bug.
> > Please always provide this, especially when proposing a -stable
> > backport. Take pity upon all the downstream kernel maintainers who are
> > staring at this wondering whether they should risk adding it to their
> > kernels.
>
> The impact appears limited to x86-32, where apply_to_page_range may miss
> updating the PMD. That leads to explosions in drivers like
>
> [ 24.227844] BUG: unable to handle page fault for address: fe036000
> [ 24.228076] #PF: supervisor write access in kernel mode
> [ 24.228294] #PF: error_code(0x0002) - not-present page
> [ 24.228494] *pde = 00000000
> [ 24.228640] Oops: 0002 [#1] SMP
> [ 24.228788] CPU: 3 PID: 1300 Comm: gem_concurrent_ Not tainted 5.9.0-rc1+ #16
> [ 24.228957] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
> [ 24.229297] EIP: __execlists_context_alloc+0x132/0x2d0 [i915]
> [ 24.229462] Code: 31 d2 89 f0 e8 2f 55 02 00 89 45 e8 3d 00 f0 ff ff 0f 87 11 01 00 00 8b 4d e8 03 4b 30 b8 5a 5a 5a 5a ba 01 00 00 00 8d 79 04 <c7> 01 5a 5a 5a 5a c7 81 fc 0f 00 00 5a 5a 5a 5a 83 e7 fc 29 f9 81
> [ 24.229759] EAX: 5a5a5a5a EBX: f60ca000 ECX: fe036000 EDX: 00000001
> [ 24.229915] ESI: f43b7340 EDI: fe036004 EBP: f6389cb8 ESP: f6389c9c
> [ 24.230072] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010286
> [ 24.230229] CR0: 80050033 CR2: fe036000 CR3: 2d361000 CR4: 001506d0
> [ 24.230385] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 24.230539] DR6: fffe0ff0 DR7: 00000400
> [ 24.230675] Call Trace:
> [ 24.230957] execlists_context_alloc+0x10/0x20 [i915]
> [ 24.231266] intel_context_alloc_state+0x3f/0x70 [i915]
> [ 24.231547] __intel_context_do_pin+0x117/0x170 [i915]
> [ 24.231850] i915_gem_do_execbuffer+0xcc7/0x2500 [i915]
> [ 24.232024] ? __kmalloc_track_caller+0x54/0x230
> [ 24.232181] ? ktime_get+0x3e/0x120
> [ 24.232333] ? dma_fence_signal+0x34/0x50
> [ 24.232617] i915_gem_execbuffer2_ioctl+0xcd/0x1f0 [i915]
> [ 24.232912] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
> [ 24.233084] drm_ioctl_kernel+0x8f/0xd0
> [ 24.233236] drm_ioctl+0x223/0x3d0
> [ 24.233505] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
> [ 24.233684] ? pick_next_task_fair+0x1b5/0x3d0
> [ 24.233873] ? __switch_to_asm+0x36/0x50
> [ 24.234021] ? drm_ioctl_kernel+0xd0/0xd0
> [ 24.234167] __ia32_sys_ioctl+0x1ab/0x760
> [ 24.234313] ? exit_to_user_mode_prepare+0xe5/0x110
> [ 24.234453] ? syscall_exit_to_user_mode+0x23/0x130
> [ 24.234601] __do_fast_syscall_32+0x3f/0x70
> [ 24.234744] do_fast_syscall_32+0x29/0x60
> [ 24.234885] do_SYSENTER_32+0x15/0x20
> [ 24.235021] entry_SYSENTER_32+0x9f/0xf2
> [ 24.235157] EIP: 0xb7f28559
> [ 24.235288] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
> [ 24.235576] EAX: ffffffda EBX: 00000005 ECX: c0406469 EDX: bf95556c
> [ 24.235722] ESI: b7e68000 EDI: c0406469 EBP: 00000005 ESP: bf9554d8
> [ 24.235869] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296
> [ 24.236018] Modules linked in: i915 x86_pkg_temp_thermal intel_powerclamp crc32_pclmul crc32c_intel intel_cstate intel_uncore intel_gtt drm_kms_helper intel_pch_thermal video button autofs4 i2c_i801 i2c_smbus fan
> [ 24.236336] CR2: 00000000fe036000
>
> It looks like kasan, xen and i915 are vulnerable.
And actual impact is "on thinkpad X60 in 5.9-rc1, screen starts
blinking after 30-or-so minutes, and macine is unusable"... that is
assuming we are taking same bug.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 21:29 ` Pavel Machek
0 siblings, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-08-21 21:29 UTC (permalink / raw)
To: Chris Wilson
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, linux-mm,
David Vrabel, Dave Airlie, Andrew Morton, Linus Torvalds,
Joerg Roedel
[-- Attachment #1.1: Type: text/plain, Size: 4260 bytes --]
Hi!
> > > 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.
> >
> > There's no description here of the user-visible effects of the bug.
> > Please always provide this, especially when proposing a -stable
> > backport. Take pity upon all the downstream kernel maintainers who are
> > staring at this wondering whether they should risk adding it to their
> > kernels.
>
> The impact appears limited to x86-32, where apply_to_page_range may miss
> updating the PMD. That leads to explosions in drivers like
>
> [ 24.227844] BUG: unable to handle page fault for address: fe036000
> [ 24.228076] #PF: supervisor write access in kernel mode
> [ 24.228294] #PF: error_code(0x0002) - not-present page
> [ 24.228494] *pde = 00000000
> [ 24.228640] Oops: 0002 [#1] SMP
> [ 24.228788] CPU: 3 PID: 1300 Comm: gem_concurrent_ Not tainted 5.9.0-rc1+ #16
> [ 24.228957] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
> [ 24.229297] EIP: __execlists_context_alloc+0x132/0x2d0 [i915]
> [ 24.229462] Code: 31 d2 89 f0 e8 2f 55 02 00 89 45 e8 3d 00 f0 ff ff 0f 87 11 01 00 00 8b 4d e8 03 4b 30 b8 5a 5a 5a 5a ba 01 00 00 00 8d 79 04 <c7> 01 5a 5a 5a 5a c7 81 fc 0f 00 00 5a 5a 5a 5a 83 e7 fc 29 f9 81
> [ 24.229759] EAX: 5a5a5a5a EBX: f60ca000 ECX: fe036000 EDX: 00000001
> [ 24.229915] ESI: f43b7340 EDI: fe036004 EBP: f6389cb8 ESP: f6389c9c
> [ 24.230072] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010286
> [ 24.230229] CR0: 80050033 CR2: fe036000 CR3: 2d361000 CR4: 001506d0
> [ 24.230385] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 24.230539] DR6: fffe0ff0 DR7: 00000400
> [ 24.230675] Call Trace:
> [ 24.230957] execlists_context_alloc+0x10/0x20 [i915]
> [ 24.231266] intel_context_alloc_state+0x3f/0x70 [i915]
> [ 24.231547] __intel_context_do_pin+0x117/0x170 [i915]
> [ 24.231850] i915_gem_do_execbuffer+0xcc7/0x2500 [i915]
> [ 24.232024] ? __kmalloc_track_caller+0x54/0x230
> [ 24.232181] ? ktime_get+0x3e/0x120
> [ 24.232333] ? dma_fence_signal+0x34/0x50
> [ 24.232617] i915_gem_execbuffer2_ioctl+0xcd/0x1f0 [i915]
> [ 24.232912] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
> [ 24.233084] drm_ioctl_kernel+0x8f/0xd0
> [ 24.233236] drm_ioctl+0x223/0x3d0
> [ 24.233505] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
> [ 24.233684] ? pick_next_task_fair+0x1b5/0x3d0
> [ 24.233873] ? __switch_to_asm+0x36/0x50
> [ 24.234021] ? drm_ioctl_kernel+0xd0/0xd0
> [ 24.234167] __ia32_sys_ioctl+0x1ab/0x760
> [ 24.234313] ? exit_to_user_mode_prepare+0xe5/0x110
> [ 24.234453] ? syscall_exit_to_user_mode+0x23/0x130
> [ 24.234601] __do_fast_syscall_32+0x3f/0x70
> [ 24.234744] do_fast_syscall_32+0x29/0x60
> [ 24.234885] do_SYSENTER_32+0x15/0x20
> [ 24.235021] entry_SYSENTER_32+0x9f/0xf2
> [ 24.235157] EIP: 0xb7f28559
> [ 24.235288] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
> [ 24.235576] EAX: ffffffda EBX: 00000005 ECX: c0406469 EDX: bf95556c
> [ 24.235722] ESI: b7e68000 EDI: c0406469 EBP: 00000005 ESP: bf9554d8
> [ 24.235869] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296
> [ 24.236018] Modules linked in: i915 x86_pkg_temp_thermal intel_powerclamp crc32_pclmul crc32c_intel intel_cstate intel_uncore intel_gtt drm_kms_helper intel_pch_thermal video button autofs4 i2c_i801 i2c_smbus fan
> [ 24.236336] CR2: 00000000fe036000
>
> It looks like kasan, xen and i915 are vulnerable.
And actual impact is "on thinkpad X60 in 5.9-rc1, screen starts
blinking after 30-or-so minutes, and macine is unusable"... that is
assuming we are taking same bug.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 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] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 12:37 ` [Intel-gfx] " Joerg Roedel
@ 2020-08-21 22:34 ` Andrew Morton
-1 siblings, 0 replies; 29+ messages in thread
From: Andrew Morton @ 2020-08-21 22:34 UTC (permalink / raw)
To: Joerg Roedel
Cc: linux-mm, linux-kernel, Chris Wilson, intel-gfx, Pavel Machek,
Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi,
David Vrabel, Joerg Roedel, stable
On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> Cc: <stable@vger.kernel.org> # v5.8+
I'm trying to figure out how you figured out that this is 5.8+. Has a
particular misbehaving commit been identified?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 22:34 ` Andrew Morton
0 siblings, 0 replies; 29+ messages in thread
From: Andrew Morton @ 2020-08-21 22:34 UTC (permalink / raw)
To: Joerg Roedel
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, Chris Wilson,
linux-mm, David Vrabel, Pavel Machek, Dave Airlie,
Linus Torvalds
On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> Cc: <stable@vger.kernel.org> # v5.8+
I'm trying to figure out how you figured out that this is 5.8+. Has a
particular misbehaving commit been identified?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 22:34 ` [Intel-gfx] " Andrew Morton
@ 2020-08-21 23:39 ` Chris Wilson
-1 siblings, 0 replies; 29+ messages in thread
From: Chris Wilson @ 2020-08-21 23:39 UTC (permalink / raw)
To: Andrew Morton, Joerg Roedel
Cc: linux-mm, linux-kernel, intel-gfx, Pavel Machek, Linus Torvalds,
Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel,
Joerg Roedel, stable
Quoting Andrew Morton (2020-08-21 23:34:12)
> On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
> >
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> > Cc: <stable@vger.kernel.org> # v5.8+
>
> I'm trying to figure out how you figured out that this is 5.8+. Has a
> particular misbehaving commit been identified?
The two commits of relevance, in my eyes, were
2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified")
86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")
I can reproduce the failure on v5.8, but not on v5.7. A bisect would
seem to be plausible.
-Chris
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-21 23:39 ` Chris Wilson
0 siblings, 0 replies; 29+ messages in thread
From: Chris Wilson @ 2020-08-21 23:39 UTC (permalink / raw)
To: Andrew Morton, Joerg Roedel
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, linux-mm,
David Vrabel, Pavel Machek, Dave Airlie, Linus Torvalds
Quoting Andrew Morton (2020-08-21 23:34:12)
> On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
> >
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> > Cc: <stable@vger.kernel.org> # v5.8+
>
> I'm trying to figure out how you figured out that this is 5.8+. Has a
> particular misbehaving commit been identified?
The two commits of relevance, in my eyes, were
2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified")
86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")
I can reproduce the failure on v5.8, but not on v5.7. A bisect would
seem to be plausible.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 23:39 ` [Intel-gfx] " Chris Wilson
@ 2020-08-22 11:31 ` Chris Wilson
-1 siblings, 0 replies; 29+ messages in thread
From: Chris Wilson @ 2020-08-22 11:31 UTC (permalink / raw)
To: Andrew Morton, Joerg Roedel
Cc: linux-mm, linux-kernel, intel-gfx, Pavel Machek, Linus Torvalds,
Dave Airlie, Joonas Lahtinen, Rodrigo Vivi, David Vrabel,
Joerg Roedel, stable
Quoting Chris Wilson (2020-08-22 00:39:09)
> Quoting Andrew Morton (2020-08-21 23:34:12)
> > On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
> > >
> > > Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> > > Cc: <stable@vger.kernel.org> # v5.8+
> >
> > I'm trying to figure out how you figured out that this is 5.8+. Has a
> > particular misbehaving commit been identified?
>
> The two commits of relevance, in my eyes, were
>
> 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified")
> 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")
>
> I can reproduce the failure on v5.8, but not on v5.7. A bisect would
> seem to be plausible.
The active ingredient was
7f0a002b5a21 ("x86/mm: remove vmalloc faulting")
which explains a lot.
-Chris
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-22 11:31 ` Chris Wilson
0 siblings, 0 replies; 29+ messages in thread
From: Chris Wilson @ 2020-08-22 11:31 UTC (permalink / raw)
To: Andrew Morton, Joerg Roedel
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, linux-mm,
David Vrabel, Pavel Machek, Dave Airlie, Linus Torvalds
Quoting Chris Wilson (2020-08-22 00:39:09)
> Quoting Andrew Morton (2020-08-21 23:34:12)
> > On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel <joro@8bytes.org> 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.
> > >
> > > Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> > > Cc: <stable@vger.kernel.org> # v5.8+
> >
> > I'm trying to figure out how you figured out that this is 5.8+. Has a
> > particular misbehaving commit been identified?
>
> The two commits of relevance, in my eyes, were
>
> 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified")
> 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")
>
> I can reproduce the failure on v5.8, but not on v5.7. A bisect would
> seem to be plausible.
The active ingredient was
7f0a002b5a21 ("x86/mm: remove vmalloc faulting")
which explains a lot.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 19:18 ` Linus Torvalds
@ 2020-08-22 16:12 ` Joerg Roedel
-1 siblings, 0 replies; 29+ messages in thread
From: Joerg Roedel @ 2020-08-22 16:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Joerg Roedel, Andrew Morton, Linux-MM, Linux Kernel Mailing List,
Chris Wilson, intel-gfx, Pavel Machek, Dave Airlie,
Joonas Lahtinen, Rodrigo Vivi, David Vrabel, stable
On Fri, Aug 21, 2020 at 12:18:41PM -0700, Linus Torvalds wrote:
> It also strikes me that I think the only architecture that uses the
> whole arch_sync_kernel_mappings() thing is now just x86-32.
>
> [ Well, x86-64 still has it, but that's because we undid the 64-bit
> removal, but it's on the verge of going away and x86-64 shouldn't
> actually _need_ it any more ]
>
> So all of this seems to be purely for 32-bit x86. Which kind of makes
> this all fail the smell test.
Yeah, it is certainly not the nicest thing to have in generic mm code,
but at least it is an improvement of the vmalloc_sync_all() interface we
had before, where the function had to be called at random undefined
places.
And x86-32 needs it, as long as we have the !SHARED_KERNEL_PMD cases
(which includes legacy paging). Or we also pre-allocate the PMDs on
x86-32 and forbid large ioremap mappings. But since the vmalloc area
gets larger with less RAM on x86-32, this would penalize low memory
machines by using more pages for the pre-allocations.
Not sure if making the vmalloc area on x86-32 a fixed 128MB range of
address space independent of RAM size is doable or if it will break some
machines. But with that pre-allocating PMDs would make more sense and we
could get rid of the p?d_alloc_track() stuff.
Regards,
Joerg
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-22 16:12 ` Joerg Roedel
0 siblings, 0 replies; 29+ messages in thread
From: Joerg Roedel @ 2020-08-22 16:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Joerg Roedel, Linux Kernel Mailing List, stable, Chris Wilson,
Linux-MM, David Vrabel, Pavel Machek, Dave Airlie, Andrew Morton,
intel-gfx
On Fri, Aug 21, 2020 at 12:18:41PM -0700, Linus Torvalds wrote:
> It also strikes me that I think the only architecture that uses the
> whole arch_sync_kernel_mappings() thing is now just x86-32.
>
> [ Well, x86-64 still has it, but that's because we undid the 64-bit
> removal, but it's on the verge of going away and x86-64 shouldn't
> actually _need_ it any more ]
>
> So all of this seems to be purely for 32-bit x86. Which kind of makes
> this all fail the smell test.
Yeah, it is certainly not the nicest thing to have in generic mm code,
but at least it is an improvement of the vmalloc_sync_all() interface we
had before, where the function had to be called at random undefined
places.
And x86-32 needs it, as long as we have the !SHARED_KERNEL_PMD cases
(which includes legacy paging). Or we also pre-allocate the PMDs on
x86-32 and forbid large ioremap mappings. But since the vmalloc area
gets larger with less RAM on x86-32, this would penalize low memory
machines by using more pages for the pre-allocations.
Not sure if making the vmalloc area on x86-32 a fixed 128MB range of
address space independent of RAM size is doable or if it will break some
machines. But with that pre-allocating PMDs would make more sense and we
could get rid of the p?d_alloc_track() stuff.
Regards,
Joerg
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-22 11:31 ` [Intel-gfx] " Chris Wilson
@ 2020-08-22 16:20 ` Joerg Roedel
-1 siblings, 0 replies; 29+ messages in thread
From: Joerg Roedel @ 2020-08-22 16:20 UTC (permalink / raw)
To: Chris Wilson
Cc: Andrew Morton, Joerg Roedel, linux-mm, linux-kernel, intel-gfx,
Pavel Machek, Linus Torvalds, Dave Airlie, Joonas Lahtinen,
Rodrigo Vivi, David Vrabel, stable
On Sat, Aug 22, 2020 at 12:31:55PM +0100, Chris Wilson wrote:
> The active ingredient was
>
> 7f0a002b5a21 ("x86/mm: remove vmalloc faulting")
Right, that is what bisection will point to. Thanks for collecting all
the info and updating the commit message!
Regards,
Joerg
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-22 16:20 ` Joerg Roedel
0 siblings, 0 replies; 29+ messages in thread
From: Joerg Roedel @ 2020-08-22 16:20 UTC (permalink / raw)
To: Chris Wilson
Cc: intel-gfx, linux-kernel, stable, linux-mm, David Vrabel,
Pavel Machek, Dave Airlie, Andrew Morton, Linus Torvalds,
Joerg Roedel
On Sat, Aug 22, 2020 at 12:31:55PM +0100, Chris Wilson wrote:
> The active ingredient was
>
> 7f0a002b5a21 ("x86/mm: remove vmalloc faulting")
Right, that is what bisection will point to. Thanks for collecting all
the info and updating the commit message!
Regards,
Joerg
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 20:50 ` [Intel-gfx] " Chris Wilson
@ 2020-08-22 21:25 ` Pavel Machek
-1 siblings, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-08-22 21:25 UTC (permalink / raw)
To: Chris Wilson
Cc: Andrew Morton, Joerg Roedel, linux-mm, linux-kernel, intel-gfx,
Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi,
David Vrabel, Joerg Roedel, stable
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Hi!
> > > 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.
> >
> > There's no description here of the user-visible effects of the bug.
> > Please always provide this, especially when proposing a -stable
> > backport. Take pity upon all the downstream kernel maintainers who are
> > staring at this wondering whether they should risk adding it to their
> > kernels.
>
> The impact appears limited to x86-32, where apply_to_page_range may miss
> updating the PMD. That leads to explosions in drivers like
Is this alone supposed to fix my problems with graphics on Thinkpad
X60? Let me try...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-22 21:25 ` Pavel Machek
0 siblings, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-08-22 21:25 UTC (permalink / raw)
To: Chris Wilson
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, linux-mm,
David Vrabel, Dave Airlie, Andrew Morton, Linus Torvalds,
Joerg Roedel
[-- Attachment #1.1: Type: text/plain, Size: 1028 bytes --]
Hi!
> > > 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.
> >
> > There's no description here of the user-visible effects of the bug.
> > Please always provide this, especially when proposing a -stable
> > backport. Take pity upon all the downstream kernel maintainers who are
> > staring at this wondering whether they should risk adding it to their
> > kernels.
>
> The impact appears limited to x86-32, where apply_to_page_range may miss
> updating the PMD. That leads to explosions in drivers like
Is this alone supposed to fix my problems with graphics on Thinkpad
X60? Let me try...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 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] 29+ messages in thread
* Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
2020-08-21 12:37 ` [Intel-gfx] " Joerg Roedel
@ 2020-08-23 10:44 ` Pavel Machek
-1 siblings, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-08-23 10:44 UTC (permalink / raw)
To: Joerg Roedel
Cc: Andrew Morton, linux-mm, linux-kernel, Chris Wilson, intel-gfx,
Linus Torvalds, Dave Airlie, Joonas Lahtinen, Rodrigo Vivi,
David Vrabel, Joerg Roedel, stable
[-- Attachment #1: Type: text/plain, Size: 800 bytes --]
Hi!
> 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.
>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> Cc: <stable@vger.kernel.org> # v5.8+
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
This seems to solve screen blinking problems on Thinkpad X60. (It
already survived few unison runs, which would usually kill it.).
Tested-by: Pavel Machek <pavel@ucw.cz>
Thanks and best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Intel-gfx] [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
@ 2020-08-23 10:44 ` Pavel Machek
0 siblings, 0 replies; 29+ messages in thread
From: Pavel Machek @ 2020-08-23 10:44 UTC (permalink / raw)
To: Joerg Roedel
Cc: Joerg Roedel, intel-gfx, linux-kernel, stable, Chris Wilson,
linux-mm, David Vrabel, Dave Airlie, Andrew Morton,
Linus Torvalds
[-- Attachment #1.1: Type: text/plain, Size: 800 bytes --]
Hi!
> 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.
>
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> #x86-32
> Cc: <stable@vger.kernel.org> # v5.8+
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
This seems to solve screen blinking problems on Thinkpad X60. (It
already survived few unison runs, which would usually kill it.).
Tested-by: Pavel Machek <pavel@ucw.cz>
Thanks and best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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] 29+ messages in thread
end of thread, other threads:[~2020-08-23 10:45 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-21 12:37 [PATCH v2] mm: Track page table modifications in __apply_to_page_range() Joerg Roedel
2020-08-21 12:37 ` [Intel-gfx] " Joerg Roedel
2020-08-21 13:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-08-21 16:39 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-08-21 18:51 ` [PATCH v2] " Chris Wilson
2020-08-21 18:51 ` [Intel-gfx] " Chris Wilson
2020-08-21 19:18 ` Linus Torvalds
2020-08-21 19:18 ` [Intel-gfx] " Linus Torvalds
2020-08-21 19:18 ` Linus Torvalds
2020-08-22 16:12 ` Joerg Roedel
2020-08-22 16:12 ` [Intel-gfx] " Joerg Roedel
2020-08-21 20:35 ` Andrew Morton
2020-08-21 20:35 ` [Intel-gfx] " Andrew Morton
2020-08-21 20:50 ` Chris Wilson
2020-08-21 20:50 ` [Intel-gfx] " Chris Wilson
2020-08-21 21:29 ` Pavel Machek
2020-08-21 21:29 ` [Intel-gfx] " Pavel Machek
2020-08-22 21:25 ` Pavel Machek
2020-08-22 21:25 ` [Intel-gfx] " Pavel Machek
2020-08-21 22:34 ` Andrew Morton
2020-08-21 22:34 ` [Intel-gfx] " Andrew Morton
2020-08-21 23:39 ` Chris Wilson
2020-08-21 23:39 ` [Intel-gfx] " Chris Wilson
2020-08-22 11:31 ` Chris Wilson
2020-08-22 11:31 ` [Intel-gfx] " Chris Wilson
2020-08-22 16:20 ` Joerg Roedel
2020-08-22 16:20 ` [Intel-gfx] " Joerg Roedel
2020-08-23 10:44 ` Pavel Machek
2020-08-23 10:44 ` [Intel-gfx] " Pavel Machek
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.