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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> 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.

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