On Tue, 11 Mar 2014 18:40:23 +0000 David Vrabel <[email protected]> wrote:
> 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 <[email protected]> > Signed-off-by: David Vrabel <[email protected]> > --- > 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); > } Worried. This adds a schedule into a previously atomic function. Are there any callers which call into here from interrupt or with a lock held, etc? I started doing an audit, got to mvebu_hwcc_dma_ops.free->__dma_free_remap->unmap_kernel_range->vunmap_page_range and gave up - there's just too much. The best I can suggest is to do --- a/mm/vmalloc.c~mm-vmalloc-avoid-soft-lockup-warnings-when-vunmaping-large-ranges-fix +++ a/mm/vmalloc.c @@ -71,6 +71,8 @@ static void vunmap_pmd_range(pud_t *pud, pmd_t *pmd; unsigned long next; + might_sleep(); + pmd = pmd_offset(pud, addr); do { next = pmd_addr_end(addr, end); so we at least find out about bugs promptly, but that's a pretty lame approach. Who the heck is mapping 50GB? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
