Kernel module null pointer error when a function is *moved* to another file.
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Kernel module null pointer error when a function is *moved* to another file.
Hi,
I have a function for SHA1 computation which I'm trying to test. When I put the function definition in the main module file (i.e., the one that contains module_init and module_exit), it works fine. When I move it to another file (which, of course, is linked), the function runs partially but has a null pointer dereferencing halfway through. I have no idea why this should happen... it's not a linking error since the bug happens somewhere halfway down in the function. I'm using kernel 2.6.22.14.
This is the demsg output (code and makefile attached below):
This is the "util.c" file which I'm trying to link with test1.c. "util.h" just contains the prototypes for the below two functions. There are a few printks, and it appears that the null pointer dereferencing is happening at the "crypto_hash_digest" call below (although, in the printk just above the call, all arguments are non-null and print just fine). If you just copy these functions to the beginning of test1.c (and not include util.h or link with util.c), it will work fine.
Also make sure that all of the affected source-code has been recompiled and relinked ... and of course, reinstalled. (If you're encountering a zero, it's pretty much definite that it hasn't.)
Last edited by sundialsvcs; 03-02-2009 at 07:28 AM.
Valery Reznic, sundialsvcs, thanks for your replies.
Valery Reznic: I've not used objdump before, but how will knowing the offset the call to 'crypto_hash_digest' in 'get_sha1_2' help me debug? What I mean to say is: aren't the addresses printed on the Oops are different from the static .o/.ko files? Thanks for the pointer; I will look further into objdump and also gdb/kgdb.
sundialsvcs: Yes, all sources were recompiled and relinked (in fact, when I replace the sha1 function with a dummy function), other parts of my code also work. As I said, the same function, when defined in test1.c, gives the correct sha1sum.
I'm wondering if it is something to do with the crypto API call, which uses a 'struct scatterlist' to read input to compute the digest. the struct is defined like this (asm-i386/scatterlist.h):
struct scatterlist {
struct page ∗page;
unsigned int offset;
dma_addr_t dma_address;
unsigned int length;
};
This representation (AFAICT) is to speed up hashing large chunks of data (as opposed to hashing small strings). I see a 'do_page_fault' (which could be benign too, i suppose) in the Oops dmesg, so I'm wondering if it's something to do with that.
Valery Reznic, sundialsvcs, thanks for your replies.
Valery Reznic: I've not used objdump before, but how will knowing the offset the call to 'crypto_hash_digest' in 'get_sha1_2' help me debug? What I mean to say is: aren't the addresses printed on the Oops are different from the static .o/.ko files? Thanks for the pointer; I will look further into objdump and also gdb/kgdb.
/QUOTE]
I think after Ooops you have reboot to make another try ?
So if Ooops and objdump provide exactly same information objdump looks like more quick (and safe way.
You can compare objdump's output for working and not working .ko files.
It may be informative.
Could you post both of them ?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.