> > That said, I think that's true of uprobes too. Why the f*ck would > uprobes do it's "munmap" operation when we walk the page tables? This > function was called by more than just the actual unmapping, it was > called by stuff that wants to zap the pages but leave the mapping > around. > This was pointed out by Oleg earlier and I had moved the code to unlink_file_vma. However by the time unlink_file_vma() is called, the pages would have been unmapped (in unmap_vmas()) and the task->rss_stat counts accounted (in zap_pte_range()). If the exiting process has probepoints, uprobe_munmap() checks if the breakpoint instruction was around before decrementing the probe count. This check results in a file backed page being re-read by uprobe_munmap() and also it cannot find the breakpoint (because we read a file backed page). i.e 1. The task->rss_stat counts gets incremented again because we have read a page. 2. mm->uprobes_state.count which should have decremented, doesnt get decremented as uprobe_munmap fails to see the breakpoint. Hence I had to move back the callback to zap pages so that we do the cleanup before the task->rss_stat counts are accounted. That said, Oleg has a in-works patch/idea for removing uprobe_munmap and mm->uprobes_state.count, which when done, will remove the uprobe_munmap hook. https://lkml.org/lkml/2012/4/16/594 Please do let me know if you have better ideas to handle this. -- Thanks and Regards Srikar -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html