> > 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, 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>