Re: breakpoint assistance: single-step out of line

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Wed, 2007-03-28 at 21:40 -0700, Roland McGrath wrote:
> ...
> I'm sorry I wasn't more explicit about how to
> keep it simple.  For not even trying to do any special hiding magic, it
> didn't occur to me that you'd do anything but this:
> 
> 	#define SLOT_SIZE		...
> 	#define	SLOT_AREA_SIZE		PAGE_ALIGN(NR_CPUS * SLOT_SIZE)

We've considered per-CPU slots.  Can you guarantee that the probed
thread can't migrate to another CPU (or be preempted) between the time
we store the instruction in the slot, return from our report_signal
callback (which handles the breakpoint trap), and single-step the
instruction?  (Assume that our callback doesn't sleep in that interval.)
> 
> 		struct mm_struct *mm = current->mm;
> 		unsigned long addr;
> 
> 		down_write(&mm->mmap_sem);
> 		/*
> 		 * Find the end of the top mapping and skip a page.
> 		 * If there is no space for SLOT_AREA_SIZE above
> 		 * that, mmap will ignore our address hint.
> 		 */
> 		addr = rb_entry(rb_last(&mm->mm_rb), struct vm_area_struct,
> 				vm_rb)->vm_end + PAGE_SIZE;
> 
> 		addr = do_mmap_pgoff(NULL, addr, SLOT_AREA_SIZE, PROT_EXEC,
> 				     MAP_PRIVATE|MAP_ANONYMOUS, 0);
> 		if (addr &~ PAGE_MASK)
> 			... -errno = addr ...;
> 		up_write(&mm->mmap_sem);

We'll try this.  I looked at do_mmap_pgoff() before, and my eyes glazed
over after about 200 lines.  At least I understand what Prasanna's code
does (though I don't know all the implications of what it DOESN'T do).

do_mmap_pgoff() has to be run by the probed process,  so it can't be run
by the process that registers the first probe (typically insmod).  We
could do while handling the first probe hit, or when we quiesce the
process for the first probepoint insertion.  Any preference?  I've been
thinking about NOT quiescing for the general case of probepoint
insertion/removal for i386, x86_64, powerpc, ...

> 
> If we think up useful tweaks to make the vma more special, add (before
> up_write):
> 
> 		vma = find_vma(addr);
> 		vma->vm_flags |= VM_DONTCOPY | VM_DONTEXPAND; // or whatever
> 
> Also, doing preemptive allocation at exec time does not wash with me.  Your
> version has an extra unpageable page per process as well, 

Yeah, fixed that.

> but with a normal
> allocation it's still a gratuitous vma per process.  Most processes will
> never be probed.  I don't think this universal overhead is warranted.
> Allocating on demand at first probe insertion makes sense to me.  Using the
> top address area means it's unlikely you'll ever interfere with normal
> mappings anyway, and if somehow none available at insertion time, then
> tough, you don't insert.
> 
> Sorry, I really thought the vma was the trivial part of this and not the
> interesting one.  I'd like to see the robust instruction decoding work.
> 
> 
> Thanks,
> Roland

Jim