If vunmap() is used to unmap a large (e.g., 50 GB) region, it may take sufficiently long that it triggers soft lockup warnings. Add a cond_resched() into vunmap_pmd_range() so the calling task may be resheduled after unmapping each PMD entry. This is how zap_pmd_range() fixes the same problem for userspace mappings. All callers may sleep except for the APEI GHES driver (apei/ghes.c) which calls unmap_kernel_range_no_flush() from NMI and IRQ contexts. This driver only unmaps a single pages so don't call cond_resched() if the unmap doesn't cross a PMD boundary. Reported-by: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx> --- v2: don't call cond_resched() at the end of a PMD range. --- mm/vmalloc.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 0fdf968..1a8b162 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -75,6 +75,8 @@ static void vunmap_pmd_range(pud_t *pud, unsigned long addr, unsigned long end) if (pmd_none_or_clear_bad(pmd)) continue; vunmap_pte_range(pmd, addr, next); + if (next != end) + cond_resched(); } while (pmd++, addr = next, addr != end); } -- 1.7.2.5 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>