Using GDB for debugging netlink communication <p>I have a multi-threaded application that communicates with a kernel module using netlink sockets. One of the threads in user mode application works as a server and kernel module works as a client. Roughly the kernel code is as follows: </p> <pre><code>timeout = 3500; netlink_unicast(); wait: __set_current_state(TASK_INTERRUPTIBLE); timeout = schedule_timeout(timeout); __set_current_state(TASK_RUNNING); if (!timeout) { printk(KERN_ERR "No response received\n"); return -1; } if (message_status != UPDATED) { printk(KERN_ERR "Somebody woke us up before we got a reply. Time left %d\n", timeout); __set_current_state(TASK_INTERRUPTIBLE); goto wait; } </code></pre> <p>The <strong>message_status</strong> variable is updated in the netlink callback when the user mode application replies to this message. So basically the idea is to send a message and then wait at max timeout jiffies for the reply.</p> <p>Now, using gdb, if I add a break point in any function that is called by netlink server thread in user mode, the break point is never hit and the kernel log is flooded with messages like </p> <blockquote> <p>Somebody woke us up before we got a reply. Time left 3499</p> <p>Somebody woke us up before we got a reply. Time left 3499</p> <p>Somebody woke us up before we got a reply. Time left 3499</p> <p>Somebody woke us up before we got a reply. Time left 3499</p> <p>..</p> <p>..</p> <p>Somebody woke us up before we got a reply. Time left 3498</p> </blockquote> <p>Until I finally get </p> <blockquote> <p>No response received</p> </blockquote> <p>What is causing the kernel thread to wake up from the timeout and how should I debug the user mode code?</p> <p>PS: I am using 2.6.32-71.el6.x86_64 on RHEL 6.0</p>