Unaligned kernel access for __udivsi3_i4i

Unaligned kernel access for __udivsi3_i4i

[Drasko DRASKOVIC]

Hi all,
I am getting Unaligned kernel access on 0x809b7662

(gdb) disassemble 0x809b7662 0x809b7762
Dump of assembler code from 0x809b7662 to 0x809b7762:
0x809b7662 <__udivsi3_i4i+54>:    mov.l    @(r0,r1),r1
0x809b7664 <__udivsi3_i4i+56>:    mov    r5,r0
0x809b7666 <__udivsi3_i4i+58>:    tst    #-2,r0
0x809b7668 <__udivsi3_i4i+60>:    mova    0x809b784c <__sdivsi3_i4i+336>,r0
...


Can it be related to __udivsi3_i4i and toolchain problem, mentioned
here http://209.85.229.132/search?qÊche:7eePA2ixT4gJ:www.sfr-fresh.com/linux/misc/v2.6/ChangeLog-2.6.21+__udivsi3_i4i+unaligned+access+st+linux&cd\x10&hl=en&ct=clnk


Can this be the reason that my app is crashing (after some time) with
SIGBUS errors?


How can I further investigate problem of unaligned access in the
kernel, to check if it comes from kernel modules?


Best regards,
Drasko

Re: Unaligned kernel access for __udivsi3_i4i

[Matt Fleming]

On Sat, Feb 20, 2010 at 12:51:38AM +0100, Drasko DRASKOVIC wrote:
> Hi all,
> I am getting Unaligned kernel access on 0x809b7662

Hi Drasko,

I suspect that the reason that you're seeing these unaligned accesses is
because you are dividing by zero. That's what happens when you divide by
zero when using the libgcc softfpu divide functions; an unaligned access
is intentionally generated because SH has no other way of signalling
that an error occurred while doing the division.

To quote from gcc/config/sh/lib1func.asm in the GCC source,

"/* Lookup table translating positive divisor to index into table of
   normalized inverse.  N.B. the '0' entry is also the last entry of the
 previous table, and causes an unaligned access for division by zero.  */"

Re: Unaligned kernel access for __udivsi3_i4i

[Drasko DRASKOVIC]

On Sat, Feb 20, 2010 at 1:08 AM, Matt Fleming <matt@console-pimps.org> wrote:
> On Sat, Feb 20, 2010 at 12:51:38AM +0100, Drasko DRASKOVIC wrote:
>> Hi all,
>> I am getting Unaligned kernel access on 0x809b7662
>
> Hi Drasko,
>
> I suspect that the reason that you're seeing these unaligned accesses is
> because you are dividing by zero. That's what happens when you divide by
> zero when using the libgcc softfpu divide functions; an unaligned access
> is intentionally generated because SH has no other way of signalling
> that an error occurred while doing the division.
>
> To quote from gcc/config/sh/lib1func.asm in the GCC source,
>
> "/* Lookup table translating positive divisor to index into table of
>   normalized inverse.  N.B. the '0' entry is also the last entry of the
>  previous table, and causes an unaligned access for division by zero.  */"
>

Thanks Matt,
I saw this comment in uClibc source, but it did not make much sense to
me, because I did not know that SH4 will not go to some exception
state.

Does that mean that we can do division by zero that goes completely
unnoticed, unless we turn up the warnings (as kernel will fix these
unalignments without even reporting it)?

Doing: echo 1 > /proc/cpu/kernel_alignement, I saw that the kernel
unaligned access was reported. Would that say that some module is
trying division by zero, and not the application itself (because I did
echo 1 > /proc/cpu/alignment at the same time, and it was not reported
as User fault)? I am trying to isolate guilty party, so I would like
to know if it comes from the user space or kernel module (or kernel
itself).

Do you have some ah hoc ideas what would be best strategy to trace
this call back?

Thank you for your help and best regards,
Drasko

Re: Unaligned kernel access for __udivsi3_i4i

[Matt Fleming]

On Sat, Feb 20, 2010 at 01:24:38AM +0100, Drasko DRASKOVIC wrote:
> 
> Does that mean that we can do division by zero that goes completely
> unnoticed, unless we turn up the warnings (as kernel will fix these
> unalignments without even reporting it)?
> 

Unfortunately, yes.

> Doing: echo 1 > /proc/cpu/kernel_alignement, I saw that the kernel
> unaligned access was reported. Would that say that some module is
> trying division by zero, and not the application itself (because I did
> echo 1 > /proc/cpu/alignment at the same time, and it was not reported
> as User fault)? I am trying to isolate guilty party, so I would like
> to know if it comes from the user space or kernel module (or kernel
> itself).
> 

I would suspect that it is a kernel module that is doing the division by
zero in that case.

> Do you have some ah hoc ideas what would be best strategy to trace
> this call back?
> 

Perhaps insert a call to dump_stack() in inc_unaligned_kernel_access()?
That should give you some information about who called __udivsi3_i4i.

Re: Unaligned kernel access for __udivsi3_i4i

[Paul Mundt]

On Sat, Feb 20, 2010 at 11:47:16AM +0000, Matt Fleming wrote:
> On Sat, Feb 20, 2010 at 01:24:38AM +0100, Drasko DRASKOVIC wrote:
> > Does that mean that we can do division by zero that goes completely
> > unnoticed, unless we turn up the warnings (as kernel will fix these
> > unalignments without even reporting it)?
> 
> Unfortunately, yes.
> 
There are two sides to consider. Division by zero is generally an FPU
exception and you can instrument the FPU error exception handlers
accordingly for the cases where userspace is responsible. For the
__udivsi3_i4i case this will just result in an address error being raised
given that it's wholly integer based. The regular __udivsi3_i4 case on
the other hand will have a different exception path due to being FPU
bounded, assuming you haven't disabled FPU code for your userspace
applications.