Re: kernel unaligned acc on Alpha

[mru@kth.se (Måns Rullgård)]

Marc Giger <gigerstyle@gmx.ch> writes:

> Hi Måns,
>
> On Sun, 29 Feb 2004 22:24:45 +0100
> mru@kth.se (Måns Rullgård) wrote:
>
>> Marc Giger <gigerstyle@gmx.ch> writes:
>> 
>> > Hi All,
>> >
>> > I have a lot of unaligned accesses in kernel space:
>> >
>> > kernel unaligned acc    : 2191330
>> > (pc=fffffffc002557d8,va=fffffffc00256059)
>> >
>> > It seems to be located in the networking part (iptables?) from the
>> > kernel. Can someone please help me how to find the location of these
>> > uac's? I already have recompiled the kernel with debugging enabled
>> > and tried to debug it with gdb. 
>> 
>> Find the matching function in System.map.  Look for the entry with the
>> highest address less than or equal to the pc value.
>
> The highest address in System.map is 
> fffffc000076fab0 A _end
>
> /proc/ksyms is more informative. It seems the function is in a
> module.

Yes, of course.

> fffffffc00254800 ipt_unregister_table   [ip_tables]
> fffffffc00256051 __insmod_ip_tables_S.rodata_L16        [ip_tables]

That seems to support my suspicion that something is doing unaligned
accesses of static data.

> ipt_unregister_table is the most matching funtion, but makes no sense to
> me, since I don't load and unload it 2191330 times:-)

There is probably some function after ipt_unregister_table in the
source code that is not being exported from the object file.

> Do you have more tips how to find the right funtion in the modules?

Disassemble (objdump -s) the module and look for load or store
instructions with the same page offset as the reported pc value, in
this case 0x17d8.  You'll want to compile with debugging symbols so
you get the function names printed even for static functions.

Another thing is to look for casts to (int *) or (long *) in the
source code.  There's often one somewhere close to the unaligned
access.  You might also check where static data is being accessed.
Depending on the amount of static data and the number of accesses this
might be more trouble than it's worth.

BTW, which kernel version is this?

-- 
Måns Rullgård
mru@kth.se