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@kvack.org.  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@kvack.org"> email@kvack.org </a>