Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

[Jim Keniston]

On Fri, 2010-01-15 at 10:02 +0100, Peter Zijlstra wrote:
> On Thu, 2010-01-14 at 11:46 -0800, Jim Keniston wrote:
> > 
> > +Instruction copies to be single-stepped are stored in a per-process
> > +"single-step out of line (XOL) area," which is a little VM area
> > +created by Uprobes in each probed process's address space.
> 
> I think tinkering with the probed process's address space is a no-no.
> Have you ran this by the linux mm folks?

Sort of.

Back in 2007 (!), we were getting ready to post uprobes (which was then
essentially uprobes+xol+upb) to LKML, pondering XOL alternatives and
waiting for utrace to get pulled back into the -mm tree.  (It turned out
to be a long wait.)  I emailed Andrew Morton, inquiring about the
prospects for utrace and giving him a preview of utrace-based uprobes.
He expressed openness to the idea of allocating a piece of the user
address space for the XOL area, a la the vdso page.

With advice and review from Dave Hansen, we implemented an XOL page, set
up for every process (probed or not) along the same lines as the vdso
page.

About that time, Roland McGrath suggested using do_mmap_pgoff() to
create a separate vma on demand.  This was the seed of the current
implementation.  It had the advantages of being
architecture-independent, affecting only probed processes, and allowing
the allocation of more XOL slots.  (Uprobes can make do with a fixed
number of XOL slots -- allowing one probepoint to steal another's slot
-- but it isn't pretty.)

As I recall, Dave preferred the other idea (1 XOL page for every
process, probed or not) -- mostly because he didn't like the idea of a
new vma popping into existence when the process gets probed -- but was
OK with us going ahead with Roland's idea.

(I'm not a VM guy; pardon any imprecision in my language.)

Jim

> I'd be inclined to NAK this
> straight out.
> 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/