On Wed, 9 Jul 2014, Vlastimil Babka wrote:
> On 07/09/2014 06:03 PM, Sasha Levin wrote:
> >
> > We can see that it's not blocked since it's in the middle of a spinlock
> > unlock
> > call, and we can guess it's been in that function for a while because of
> > the hung
> > task timer, and other processes waiting on that i_mmap_mutex:
>
> Hm, zap_pte_range has potentially an endless loop due to the 'goto again'
> path. Could it be a somewhat similar situation to the fallocate problem, but
> where parallel faulters on shared memory are preventing a process from
> exiting? Although they don't fault the pages into the same address space,
> they could maybe somehow interact through the TLB flushing code? And only
> after fixing the original problem we can observe this one?
That's a good thought. It ought to make forward progress nonetheless,
but I believe (please check, I'm rushing) that there's an off-by-one in
that path which could leave us hanging - but only when __tlb_remove_page()
repeatedly fails, which would only happen if exceptionally low on memory??
Does this patch look good, and does it make any difference to the hang?
--- mmotm/mm/memory.c 2014-07-02 15:32:22.212311544 -0700
+++ linux/mm/memory.c 2014-07-09 09:56:33.724159443 -0700
@@ -1145,6 +1145,7 @@ again:
if (unlikely(page_mapcount(page) < 0))
print_bad_pte(vma, addr, ptent, page);
if (unlikely(!__tlb_remove_page(tlb, page))) {
+ addr += PAGE_SIZE;
force_flush = 1;
break;
}
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html