On 09/01/2011 17:15, omalleys(a)msu.edu wrote:
Quoting Gordan Bobic<gordan(a)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
>>>> If he doesn't use Fedora initscripts, then he's at the mercy of
>>>> kernel default alignment policy of "mangle data silently" but
>>>> 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
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
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:
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).