lkml.org 
[lkml]   [2011]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7 3.2-rc2 4/30] uprobes: Define hooks for mmap/munmap.
> > 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.
>

Okay, I will move the optimization parts into a separate patch and keep
it at the end of the patchset.

> 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.
>

Okay, will work towards this.

--
Thanks and Regards
Srikar



\
 
 \ /
  Last update: 2011-12-01 14:29    [W:0.072 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site