[fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts

[Gordan Bobic]

On 01/08/2011 07:59 PM, Chris Tyler wrote:
> On Sat, 2011-01-08 at 19:27 +0000, Gordan Bobic wrote:
>> See my argument for 1 vs 3. It's easy enough for the user to change this
>> themselves, but defaults should be providing more pressure for fixing
>> things, not less compare to the current default (0).
>>
>>>> Having a policy that alignment faults should be avoided itself is fine,
>>>> but it is not a replacement for the good assertive action made by
>>>> changing the runtime policy.  In fact I don't think we get to this point
>>>> with so few fixups unless that was already the general policy not just
>>>> here but in the upstreams.
>>>
>>> I think that might be more luck than intention. A lot of stuff is being
>>> developed on three main architectures that take care of miss-alignment.
>>
>> Maybe so, but that shouldn't be an excuse for not fixing this sort of
>> thing, especially since ARM looks set to become much more popular as a
>> desktop and server platform.
>>
>>>> When the initscripts set the runtime action to be fixup + log, those
>>>> faults will actually become more visible to everyone and help detection
>>>> and removal of faults overall.
>>>
>>> This is true. Warnings will motivate fixing stuff. Still, doesn't hurt
>>> to have some kind of "policy" to promote this. I'm only really concerned
>>> because none of the primary Fedora arches are bitten by this, so it's
>>> easy for this to continue slipping under the radar.
>>
>> Agreed - and such a policy would probably benefit from not having the
>> issue silently fixed. Silently fixing the issue at a performance penalty
>> as a policy, taken to it's final logical conclusion, means that you
>> might just as well just tell the user to run it in a qemu VM on x86.
>
> (1) I think we're agreed that silence (mode 0, ignore), the current
> default, is probably the worst possible value.
>
> (2) It's going to be really, really hard to [i] identify and [ii]
> convince upstreams to fix all alignment issues. Where alignment traps
> may be data-triggered, it will be nearly impossible to have confidence
> that all corner cases have been tested.
>
> I also think that it's unnecessary to eliminate all alignment issues --
> in many cases, kernel fixups may actually be cheaper to run than the
> defensive code necessary to avoid them, and hardware fixups are even
> cheaper. Furthermore, running on an armv7 or higher processor won't
> trigger the alignment traps at all, so we won't even know that there are
> issues (just as we don't know, nor care, in an x86 context).

It is plausible that defensively redesigned code may incur a similar 
performance hit, but philosophically, we shouldn't be aiming for 
complacency by just glazing over the issue and pretending it isn't an 
issue. ARMv5 and ARMv6 are quite capable processors and are going to be 
around for quite a while yet.

> Thus my recommendation that we warn and fix up the alignment, rather
> than warn and produce wrong results. (If you really want to force
> someone to deal with these issues, you'd want warn+signal, and I would
> strongly oppose making that the default).

I think we'll just have to agree to disagree on this, but it is probably 
not that big a deal if things go the way you suspect it might (that 
fixes will be forthcoming). There is, however, enough politics and 
ego-waving in the software development world ("my software is fine, your 
platform is broken") that I would rather take a hardline stance 
initially and then relax it if necessary in compromise than compromise 
pre-emptively and get nowhere as a result.

Gordan