* [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: [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 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: [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-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 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-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-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 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.