From: Jim Keniston <jkenisto@us.ibm.com>
To: Ernie Petrides <petrides@redhat.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
Linda Wang <lwang@redhat.com>,
systemtap@sources.redhat.com
Subject: Re: [RFC][PATCH 2/2] uprobes: single-step out of line
Date: Thu, 10 May 2007 23:17:00 -0000 [thread overview]
Message-ID: <1178835464.3753.18.camel@ibm-ni9dztukfq8.beaverton.ibm.com> (raw)
In-Reply-To: <200705090134.l491YvgW010707@pasta.boston.redhat.com>
On Tue, 2007-05-08 at 21:34 -0400, Ernie Petrides wrote:
> 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.)
Yes, I'd appreciate it if you confirm the need for a change here, since
the effort/implications for this change are non-trivial.
>
>
> Cheers. -ernie
Thanks.
Jim
next prev parent reply other threads:[~2007-05-10 23:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-05 1:07 Ernie Petrides
2007-05-07 22:02 ` Jim Keniston
2007-05-09 1:32 ` Ernie Petrides
2007-05-10 23:17 ` Jim Keniston [this message]
2007-05-11 22:31 ` Ernie Petrides
-- strict thread matches above, loose matches on Subject: below --
2007-04-20 23:10 Jim Keniston
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1178835464.3753.18.camel@ibm-ni9dztukfq8.beaverton.ibm.com \
--to=jkenisto@us.ibm.com \
--cc=fche@redhat.com \
--cc=lwang@redhat.com \
--cc=petrides@redhat.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).