Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names

[Jürgen Groß <jgross@xxxxxxxx>]

On 28.11.19 11:17, George Dunlap wrote:
> > On Nov 28, 2019, at 9:55 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> > > > > Has anyone actually tried building a livepatch with this change in place?
> > > > Actually - what is your concern here? The exact spelling of symbols
> > > > names should be of no interest to the tool. After all the compiler is
> > > > free to invent all sorts of names for its local symbols, including
> > > > the ones we would produce with this change in place. All the tool
> > > > cares about is that the names be unambiguous. Hence any (theoretical)
> > > > regression here would be a bug in the tools, which imo is no reason
> > > > to delay this change any further. (Granted I should have got to it
> > > > earlier, but it had been continuing to get deferred.)
> > > This might all be true (theoretically).
> > >
> > > The livepatch build tools are fragile and very sensitive to how the
> > > object files are laid out.  There is a very real risk that this change
> > > accidentally breaks livepatching totally, even on GCC builds.
> > >
> > > Were this to happen, it would be yet another 4.13 regression.
> > It's perhaps a matter of perception, but I'd still call this a
> > live patching tools bug then, not a 4.13 regression.
> After the discussion yesterday, I was thinking a bit more about this, and I’m not 
> happy with the principle Andy seems to be operating on, that it’s reasonable to 
> completely block a bug-fixing patch to Xen, forcing a work-around to be used in a release, 
> because it has unknown effects on livepatching.
>
> Consider the relationship between Xen and Linux, for example.  Suppose that a patch were posted to 
> Linux to fix an issue, and Juergen responded by saying that he wasn’t happy with it because 
> it  might possibly break things running under Xen.  But he didn’t actually test it himself, 
> nor propose some alternate way of fixing the original problem; rather, he expected the original 
> patch submitter, who doesn’t use Xen, to set up a Xen system and test it themselves before 
> accepting it.
>
> Do you think anyone in the kernel community would stand for that?  Of course 
> not.  Naturally the patch would be *paused* while *people in the Xen community* 
> tested and or proposed alternate solutions; but if there was a delay, 
> eventually it would be checked in.
>
> I think the same principle should apply here.  If people using the livepatch code are afraid 
> that Jan’s patch *may* affect livepatching on gcc, then they should be given time to 
> review, test, and/or propose alternate solutions.  But it should be the responsibility of 
> people working on that code, not the responsibility of developers who don’t use that 
> code.
>
> >   If they're so
> > extremely fragile, then I think this needs urgently taking care of
> > by their maintainers. As mentioned before - how exactly static
> > symbols get represented is up to the compiler, i.e. may change at
> > any time. As a result, any change whatsoever would need such
> > regression testing, no matter that I agree that a larger scope
> > change like this one has slightly higher potential of triggering
> > some issue.
> This is another argument I would agree with.
>
> Given the closeness to the release, I’d favor checking in the patch today or 
> tomorrow, regardless of testing status, so that it can get more testing in our 
> automated systems; it can always be reverted if it is shown to break livepatching on 
> gcc.
In that case: please rather today than tomorrow. The earlier the
better.

Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel