[Olsr-dev] alignment faults on ARM processors

[Henning Rogge]

Hi,

do you use any kind of special plugins? Can you maybe run gdb or 
valgrind on your architecture to collect more data?

if neither gdb nor valgrind trigger, maybe you can patch the code in 
src/lq_packet.h to trigger a segfault if its used unaligned, which would 
give us a full stacktrace with gdb:

if ((((uint32_t) *p) & 3) != 0) {
     *((uint8_t *)0) = 0;
}

I ask because the typical MIPS processors many community mesh devices 
use cannot handle unaligned word/longword access too, but we have to 
problem with them. If OLSRd would do unaligned reads/writes, we should 
have noticed a long time ago.

Henning Rogge

On 08/04/2012 12:41 AM, Peter Bigot wrote:
> On Fri Jul 27 08:50:52 CEST 2012, Henning Rogge wrote:
>> On Thu, Jul 26, 2012 at 9:11 AM, Peter Bigot <(spam-protected)> wrote:
>>> I was recently asked to validate OLSRD on a custom embedded platform
>>> involving an AT91 ARM processor and Linux 2.6.39 under OpenEmbedded
>>> Classic.  While the 0.5.5 release worked, 0.5.6-r8 and 0.6.3 produced
>>> a cascade of errors attempting to route to invalid IP addresses.
>>>
>>> A kernel error message indicated unaligned accesses.  I tracked this
>>> down to several uses of the following idiom in src/lq_packet.h:
>>>
>>>    *var = ntohl(**((const uint32_t **)p));
>>>
>>> where p is a pointer to a pointer to const uint8_t.  It seems that in
>>> recent Linux kernels CONFIG_ALIGNMENT_TRAP is enabled by default on
>>> these ARM chips, and the version of Sourcery_G++_Lite required on this
>>> platform does not support -mno-alignment-traps.  In practice, the
>>> pointer at this point did not satisfy the alignment requirements of
>>> the processor, and the kernel did not provide a recovery.
>>>
>>> I worked around this by replacing the assignment with an intermediate
>>> copy from the unaligned buffer into a 4-byte region in a local union
>>> with a uint32_t; similarly for the int16_t accesses.  I regret that I
>>> can't provide the patch (which is both trivial and a hack anyway), but
>>> thought a heads-up might be helpful for others trying to make OLSRD
>>> work in a similar environment.
>>>
>>> Peter
>>
>> Hmm... I think all original OLSR messages inside the OLSR packet are
>> well aligned, as are the fields inside the messages. Since 0.6.0 we even
>> have checks if the length of a message cannot be
>>
>> The fact that an uint8_t pointer is cast to 32 bit is okay, because the
>> uint8_t is a buffer with the packet, which contains all kind of fields
>> (but still should be well aligned).
>>
>> Can you explain a little bit more why the kernel is misbehaving? If we
>> would have unaligned word/byte access, the MIPS architecture would crash
>> every time you run OLSRd.
>
> I can't explain why it happens, just that I got the kernel alignment traps
> until I forced the alignment as described above, at which point they stopped
> happening.  In this case I was using a Marvell driver for the SD8787 (one
> from Marvell, not the one in the Linux kernel).  Whoever's responsible for
> placing the data at an unaligned location, the point is that the alignment
> requirements of the CPU weren't being satisfied and OLSR wasn't checking for
> it.
>
> I was only asked to do the basic validation of the port; I'm not actively
> involved in the development based on OLSR, so probably won't be able to
> provide any more detail.  But I did want to get a record of the issue
> out into the
> archive so the next person who runs into the problem might be able to figure
> it out faster.


-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120813/ba1b38f5/attachment.bin>