This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][PATCH 2/2] uprobes: single-step out of line
- From: Ernie Petrides <petrides at redhat dot com>
- To: Jim Keniston <jkenisto at us dot ibm dot com>
- Cc: Ernie Petrides <petrides at redhat dot com>, "Frank Ch. Eigler" <fche at redhat dot com>, Linda Wang <lwang at redhat dot com>, systemtap at sources dot redhat dot com
- Date: Tue, 08 May 2007 21:34:57 -0400
- Subject: Re: [RFC][PATCH 2/2] uprobes: single-step out of line
On Monday, 7-May-2007 at 14:2 PDT, Jim Keniston wrote:
> On Fri, 2007-05-04 at 21:09 -0400, Ernie Petrides wrote:
>
> > Is there a way to avoid adding the "uprobe_ssol_area" struct into the
> > "mm_struct"? If so, the uprobes module could be easily back-ported to
> > kABI-frozen distros of the Linux kernel. If the "mm_struct" ends up
> > getting changed, that changes the "task_struct" layout, thus breaking
> > binary compatibility with 3rd-party kernel modules. (We're not allowed
> > to do this in RHEL distros.)
>
>
> Hmmm. It does indeed change the layout of struct mm_struct. I don't
> see how it changes the layout of task_struct, since task_struct
> contains only pointers to mm_structs.
Ah, my mistake. You are correct. But because of how exported symbol
checksums are generated (recursively traversing all depended-on info),
all functions taking (task_struct *) arguments would become incompatible.
> But changing mm_struct itself is bad, right?
Besides the exported symbol versioning issue I've already explained, it
might also be the case that somewhere there is a global (or auto-class)
mm_struct. (There are a few in the base kernel, but one might argue
that there shouldn't be any in 3rd-party modules.) If there were one,
and somehow the "runt" mm_struct were referenced by a kernel built with
the uprobes infrastructure changes (expanding the mm_struct), then you
get fetch a bogus "uprobes_ssol_area" pointer off the end of an old struct.
I'm not sure how plausible this is, but it's something to consider.
> An obvious alternative is for uprobes to maintain this pointer
> in one of its own data structures. Currently, when the last uprobe
> for a process is unregistered, we discard the uprobe_process and
> uprobe_tasks, and the only thing that remains is the pointer to
> the uprobe_ssol_area (in mm_context). We need to remember that
> pointer in case the process is probed again -- we want to reuse the
> vma. [...]
Originally, I missed the point about reusing the VMA again later
(following the unregistering of the last probe). So, I guess you
do have a reasonable need for MM-persistent data.
I'm not sure what the best solution is. Maybe what you've already
got here is reasonable. I'd need to study mm_struct compatibility
issues for a while to determine if this would be a deal-breaker in
terms of the kABI issue. (We have this "#ifndef __GENKSYMS__" hack
that can sometimes be used to accommodate these sorts of structure
additions in a RHEL update to avoid the symbol checksum change, but
it's only viable if there's no true underlying compatibility problem.)
Cheers. -ernie