[parisc-linux] code 28 trap

[John Marvin]

> > http://boudicca.tux.org/hypermail/linux-kernel/2000week06/0092.html
> >
> > There was a bug in 2.3.41, looks like it didn't get fixed in .42, that
>
> Apparently it did get fixed in .42, so it might be worth finding out what
> exactly causes Grant's unaligned trap.

I'm running on a J5000, which is 99.9% the same as a C3000 if I disable
one of the processors. The only networking problem I've run into
is the one I already posted about, for which I have a workaround. I
have not run into any unaligned traps.

I also do not believe we should do an unaligned trap handler at this
point. Yes, we may have to do one for the non-standard protocols, but
the problem is that once we enable the trap handler, you might hide
a bunch of other performance degrading bugs.

In fact, I would propose that when we do the unaligned handler we
should have a way of enabling it on a per thread basis for user
processes. When I say "enable" I don't mean that we would install/deinstall
the handler, but simply have the handler do a check, and if the fault
came from user space, check the task structure to determine whether
we should fix the fault or terminate the process with a signal.

I believe that the default should be off. If a user doesn't want to
fix the problem (either due to indifference or lack of source), they
should explicitly enable the handler (perhaps by a flag bit in the
elf executable?) so that they know that they will be suffering a
performance penalty.

Of course, I'd like to do something similar for kernel unaligned faults,
i.e. only handle faults for areas where we expect them, but that is
probably not worth the effort. Handling kernel unaligned faults should
be configurable, possibly with the default on. We of course should
leave it off during development, unless we are testing areas of the
kernel that are known to produce unaligned faults, i.e. ones we
have decided not to fix, e.g. some of the networking protocols. One
possible thing we could do would be to enable the unaligned handler
by default, but have it log a message for the first kernel fault
it handles, e.g. "Unaligned fault at 0xxxx, enabling unaligned fault
handler", so at least people can be made aware that there may be
a performance issue.

My overall objective in all of this is to insure that we know of
all the cases where the kernel produces unaligned faults, and make
a conscious decision on whether or not we fix the code, rather than
hide unaligned references. My personal bias is to fix every piece
of code that produces unaligned references, but, based on the
linux-kernel thread that willy mentioned, we might not be able to
convince the maintainer of the code to accept those changes.

John Marvin
jsm@fc.hp.com