Re: Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux