On Thu, 2011-12-01 at 11:10 +0530, Srikar Dronamraju wrote: > > What I really would like is for this patch set not to have such subtle > > stuff at all, esp. at first. Once its in and its been used a bit we can > > start optimizing and add subtle crap like this. > > We actually started the discussion of why we increment the count in > mmap_uprobe() in EEXIST case (and read_opcode()). It exists for two > reasons. > - To handle fork case (that I wrote in another mail). > - To handle mremap.(the case where we are discussing now) > > I would contend that removing the breakpoint in munmap doesnt amount to > optimization. Since the start of unmap(), there cannot be another > remove_breakpoint called for the vma,vaddr tuple, until the vma is > cleaned up, or the subsequent mmap() is done. So the case of accounting > for an already decremented count should never occur. > > I was following the general convention being used within the kernel to not > bother about the area that we are going to unmap. For example: If a ptraced > area were to be unmapped or remapped, I dont see the breakpoint being > removed and added back. Also if a ptrace process is exitting, we dont go > about removing the installed breakpoints. > > Also we would still need the check for EEXIST and read_opcode for handling > the fork() case. So even if we add extra line to remove the actual > breakpoint in munmap, It doesnt make the code any more simpler. Not adding the counter now does though. The whole mm->mm_uprobes_count thing itself is basically an optimization. Without it we'll get to uprobe_notify_resume() too often, but who cares. And not having to worry about it removes a lot of this complexity. Then in the patch where you introduce this optimization you can list all the nitty gritty details of mremap/fork and counter balancing. Another point, maybe add some comments on how the generic bits of uprobe_notify_resume()/uprobe_bkpt_notifier()/uprobe_post_notifier() etc hang together and what the arch stuff should do. Currently I have to flip back and forth between those to figure out what happens. Having that information also helps validate that x86 does indeed do what is expected and helps other arch maintainers write their code without having to grok wtf x86 does. -- 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