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

[Chris Tyler]

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

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

-Chris