Re: [RFC][PATCH 2/2] uprobes: single-step out of line

[Ernie Petrides <petrides@redhat.com>]

On Thursday, 10-May-2007 at 15:17 PDT, Jim Keniston wrote:

> On Tue, 2007-05-08 at 21:34 -0400, Ernie Petrides wrote:
>
> > 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.


I've researched "mm_struct" usage in the latest RHEL5 kernel sources,
specifically looking for dependencies on the structure size and on the
offsets to the fields beyond the "mm_context_t".

As far as I can see, all of these dependencies are in the base part of
the kernel (as opposed to modules).  This suggest that the __GENKSYMS__
hack could be used to hide your new "uprobes_ssol_area" field being
added to the "mm_context_t" (to preserve exported symbol versioning)
without causing a true binary compatibility problem.

That being said, I don't represent views of the RHEL5 kernel maintainer
nor any other senior developers who might have to sign off on such a
change in the hypothetical scenario of a uprobes back-port to RHEL5.
But using __GENKSYMS__ for this situation looks safe to me.

Obviously, this is a non-issue for upstream acceptance, since all
sources are expected to be recompiled (and thus there is no attempt
to preserve kABI).  I did notice, however, that the "dumpable" field
of the "mm_struct" comes after the "mm_context_t" upstream in 2.6.21
(unlike in RHEL5).  Some other distro based on a more recent upstream
version could conceivably have an issue with this field, since it's
remotely possible (though unlikely) that a 3rd-party exec format
handler or security module might access "dumpable" (whose field
offset would change with an "mm_context_t" addition).  But this is
a somewhat far-fetched example, so all in all, you're probably okay.

Cheers.  -ernie