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

Gordan Bobic gordan at bobich.net
Sun Jan 9 12:09:18 UTC 2011


On 01/09/2011 10:55 AM, Andy Green wrote:
> On 01/08/11 19:59, Somebody in the thread at some point said:
>
>> (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).
>
> Sounds right.  The user is going to google why his log is filling with
> these warnings if he cares and the problem is bad, and this covers his
> code as well as distro code (with the small window where the alignment
> policy is still 0 from running init through actually setting the
> alignment policy to fix+log if he doesn't know about the kernel parameter).
>
> If he doesn't use Fedora initscripts, then he's at the mercy of the
> kernel default alignment policy of "mangle data silently" but that's not
> a Fedora problem.

In can, however, see one good argument for warn+signal, and that is that 
abrt already picks up crashes for reporting so no change would be 
required there. Also a core dump would be useful to pin down the errors 
that aren't trivial to reproduce.

Gordan


More information about the arm mailing list