Hi,

I'm developing a kernel module that is dereferences null pointer. I get Oops message, but its stack trace doesn't match with what my code is doing. For example:

[<c110b282>] ? kobject_get+0x12/0x20
[<c1102c00>] ? exact_match+0x0/0x10
[<c10ff3e5>] ? blk_register_queue+0x45/0xb0
[<c1102c00>] ? exact_match+0x0/0x10
[<c1103822>] ? add_disk+0xe2/0x130
[<c1102c00>] ? exact_match+0x0/0x10
[<c11031d0>] ? exact_lock+0x0/0x20
[<e43da15c>] ? module_init+0x15c/0x22a

so here, my module_init function calls add_disk directly, but I'm seeing exact_* functions called in between.

Is this a usual behavior of stack trace? Is there a way to get this correctly?

Thanks,

Which kernel are you using?

I'm not much following what your kernel module's doing, but there has been a patch against just about every kernel ever made, that deals with a null-dereferencing bug which has been in the kernel for a long time; maybe you should update to a newer kernel, or Patch your kernel to avoid the bug?


Sasha

Hi, Sasha

This is actually happening in my own module, so it's easy for me to debug this particular issue, but in general, when the stack trace is not accurate, it makes it harder to pinpoint the issue. And the Oops message stack trace does not correspond to my module's execution path, such as having some calls that my code never made. My question is, how do you get an accurate stack trace in the Oops message, or if that's not possible, how is one supposed to interpret the stack trace in Oops message?

Thanks!