3

Whenever I put any printk statements inside if-else block, it simply crashes the kernel in Linux.

A sample code is given below:

if (device-> Some condition) {
        s = 0;
        e = 0;
        printk(KERN_INFO "I am 0 and 0 part \n");
        printk(KERN_ALERT "KERN_INFO Successfully registered module \n");
} else {
        s = 1;
        e = 2;
        printk(KERN_INFO "I am in 1 and 1 part \n");
}

The above code gets successfully compiled when I make it. But during insmod kernel stops responding and ultimately crashes. On the contrary, if I comment out those printk statements then I could easily do insmod .

I would like to know the probable cause of this behavior and how could I remove such things.

halfer
  • 19,824
  • 17
  • 99
  • 186
user3243499
  • 2,953
  • 6
  • 33
  • 75
  • 4
    I doubt the crash has anything to do with `printk` calls. You probably have some access violation (*UB*) elsewhere and it manifests when you call `printk`. – P.P Jan 06 '16 at 11:41
  • Yes, I'm not sure about the crash, since I am using putty to RDP to a remote server. So whenever I use printk inside some if-else block (NOT ALL) it simply does not responds when I do insmod. Also, in printk I'm just printing a string and I'm not even trying to print the value of a variable. So I think it has to do with the printk statements – user3243499 Jan 06 '16 at 11:45
  • Kernel crashes generally print the exact error and a stack trace on the console. – stark Jan 06 '16 at 11:57
  • 1
    Are you shure that `device` can't be `NULL`? Without kernel stack trace it's difficult to say. – sheikh_anton Jan 06 '16 at 12:04
  • with all 3 printk you see issue? or with only any one from this 3 you see this issue? Try to narrow down the causing statements ... – Jeegar Patel Jan 06 '16 at 12:12
  • I don't have physical access to the server. I am using "putty" to remotely log into it. So in such cases, putty stops responding and becomes inactive due to Fatal error. And after some time say 30 secs, I could again reconnect to the remote linux server. So I assume that the kernel crashes and recovers – user3243499 Jan 06 '16 at 12:13
  • @coredump : Without those printk messages the logic perfectly works and loads as a kernel module. So I don't think its the issue with the device checking. – user3243499 Jan 06 '16 at 12:14
  • @JeegarPatel : I have tried will all the possible combinations. Problem is even if I had a single printk I get this issue. But this issue occurs only when it is placed inside the IF or IF - ELSE block. Outside the IF block, printk does not arise any such issues – user3243499 Jan 06 '16 at 12:16
  • The `device-> some condition` looks very suspicious. You have to provide more context of your problem, including excerpts from log files. – 0andriy Jan 08 '16 at 07:36

1 Answers1

0

There are some cases where printk should not be called see

http://lkml.iu.edu/hypermail/linux/kernel/0606.1/2198.html

and

printk inside an interrupt handler , is it really that bad?

So if your whole code is in such cases then avoid printK() try with other alternate option dev_dbg() or trace_printk()

Community
  • 1
  • 1
Jeegar Patel
  • 26,264
  • 51
  • 149
  • 222
  • It's just a simple IF-ELSE block man. I swear this is the exact code which I am using (except made some changes in the device-> condition, but that is part of the condition statement). Inside block is the same. Also, I just tried with the trace_printk() method, and it is also showing the same issue – user3243499 Jan 06 '16 at 12:46
  • One more thing Jeegar, can you tell me the reason of the following event. When I reconnect to the remote server after say 30 secs after this issue occurrence, all the files like Module.symvers, *ko etc files are deleted as if I have issued a make clean command. Why is that ? – user3243499 Jan 06 '16 at 12:49
  • When crash happen after that may be your remoter system reboot it self. and init service some rule should be there to clean those files. whats your system at remote? completer x86 system? tried with /proc/kmsg ? – Jeegar Patel Jan 06 '16 at 12:59
  • It's a x64 SLES system – user3243499 Jan 07 '16 at 07:21