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

[Gordan Bobic]

On 09/01/2011 17:15, omalleys at msu.edu wrote:
> Quoting Gordan Bobic<gordan at bobich.net>:
>
>> On 01/09/2011 12:29 PM, Andy Green wrote:
>>> On 01/09/11 12:09, Somebody in the thread at some point said:
>>>
>>>>> 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.
>>>
>>> Signal is pretty violent if, for example, once in a blue moon even init
>>> or sshd can blow an alignment fault for some reason. It'd be very
>>> interesting to find it in the logs but less interesting to find your
>>> embedded Fedora device at the bottom of the ocean can't be logged into
>>> any more for no real reason.
>>
>> I understand your point, but we're talking about defaults here, not
>> specialist defices that were deployed by people knowledgeable of what
>> they are doing. Fedora is a development/testing distribution, no a
>> production/stable/enterprise one. Whould there ever be a release of RHEL
>> for ARM, then that should perhaps have alignment=3 as default, and
>> perhaps Fedora should have alignment=5 as default.
>
> What you are talking about is a Segfault release. like make rawhide,
> alpha, beta, releases default to segfaults or at least proficiency log
> and report accurately enough to be able to find the errors to be fixed.
>
> Then for the actual release change the default so they get fixed up.
> We don't want to alienate people from the project and have it called
> buggy because it keeps crashing.

The buggyness would be the same. What we are debating there is 
buggy-and-crashing vs buggy-and-not-crashing.

The correct solution to buggy software is bug free software. I'm not 
sure reducing the visibility of the problem is the way forward on a 
mainline following distribution. Anybody running Fedora should be aware 
that it is not a stable distribution, and shouldn't be used in 
production without extensive testing by the end user. That's not to say 
there's anything wrong with Fedora, but it really shouldn't be expected 
to "just work" for everyone. It never did, it never will, that is the 
nature of bleeding edge distributions.

I just think it would be more useful WRT to actually producing a stable, 
bug free code base to optimize toward providing good, useful information 
for fixing things - and core dumps caused by unaligned data access would 
go further toward this than just fixing it up transparently and 
pretending it never happened.

Having said that, I think what you suggested is a reasonable compromise 
(I know I'm unlikely to win this argument. ;) ) - until it is release, 
have the default set to warn+signal in rawhide and next/alpha/beta, and 
when it is cooked enough for a release, relax it to fixup+warn. Still, 
at this point, the warnings should be picked up by abrt.

Which gets us to the next question - what configuration changes do we 
need for abrt for it to pick up the warnings and submit them to bugzilla?

> Does Neon, vFPU or any other simd besides sse<  2, actually do
> alignment fixups?
> Can tree-autovec handle unaligned data?

I don't think SIMD is possible on unaligned data. What you CAN do is 
loop peeling. Unroll the first few entries in the loop until the data 
aligns and then vectorize from then on. This is strictly a compile time 
thing, though.

Note that from what I understand, this isn't an issue for compile time 
assigned structures (compiler sorts this out). The problem with 
unaligned access in otherwise OK code comes from user-data processing, 
e.g. if you have data in a buffer, you're scanning it, and find where 
what you're looking for starts, and then just set a pointer to the 
starting point, you have to make sure that that pointer aligns to a 
boundary. If it doesn't you'll get unaligned access and read in data 
that is truncated (might as well be garbage). Somebody please correct me 
if I'm wrong here.

> The logistics of fixing all of them even for large projects is going
> to take a long time unless someone has a killer compiler that can do
> like a direct download from git, compile it, find the errors, fix the
> errors and submit the patches back that make sense.  :P

In fairness, not that much is actually broken, at least not that I've 
found so far. Certainly not enough to totally cripple things. So far, 
the things I've bumped into personally are:

udisks
source-highlight
dietlibc used to be problematic (that's kind of where this thread 
started), but the maintainer is really responsive, I've been testing the 
new patches for the last day and a half, and there has been considerable 
progress. I'm really, really impressed.

Somebody mentioned PHP.

I'm sure there are other things remaining, but so far it's not actually 
too bad. I'm sure a lot of work will be needed - I spent several 
hours/day for the last few days just testing and filing bug reports on 
this; but it isn't an unfeasibly large effort if the package developers 
show a willingness to address the issue (like the dietlibc maintainer has).

Gordan