Home/ Questions/Q 6369123
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T00:45:45+00:00

I wrote kernel module which do nf_register_hook and use character device mechanism to get

  • 0

I wrote kernel module which do nf_register_hook and use character device mechanism to get grabbed packets to userspace with device read hooking. I use global buffer and buffersize vars that’s why i need to lock it when new packet comes or user reading my device.
I used splinlock_irqsave and spin_unlock_irqrestore(&locker,flags) but my module went into deadlock and system freezes.

unsigned int main_hook(unsigned int hooknum, struct sk_buff *skb,
const struct net_device *in, const struct net_device *out,
int(*okfn)(struct sk_buff*)) {
unsigned long flags;
spin_lock_irqsave(&locker,flags);
...
spin_unlock_irqrestore(&locker,flags);
}

ssize_t sniffer_dev_read(struct file *filep, char *buff, size_t count, loff_t *offp) {
spin_lock_irqsave(&locker,flags);
...
spin_unlock_irqrestore(&locker,flags);
}

main_hook is registered in nf_register_hook()
sniffer_dev_read is registered in register_chrdev

when the user read from device, system go to deadlock.
ideas?
or may be irq save/restore incompatible with netfiler hook/char device read and i must use special locking here?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First, you should recompile your kernel with the lock debugging options enabled and try it again. They can help point to the cause.

    There are several possible causes for a deadlock in spin_lock_irqsave. It could be recursive locking (that is, you are trying to call spin_lock_* again within the section of code where you hold the spin lock locked). It could be that you are sleeping with the spin lock locked (do not do this ever – for each function you call with the lock held, you must known whether it can sleep or not). It could be an AB/BA deadlock (one part of the code locks A first and then B; another part locks B first then A; if the first part locked A but not B and the second part locked B but not A you have a deadlock). And so on. The lock debugging options can detect and warn you about many of these.

    Since what you are locking is a “global buffer and buffersize vars”, try to reduce the locked area to a minimum. Instead of locking at the top of the function and unlocking at the end, do as much as possible outside the lock and lock only while manipulating your buffer. Ideally, the locked section would be just a few instructions with no function calls. It is much harder to deadlock in that case.

    Now that I said all that, my attempt at psychic debugging (i.e. guessing where the problem is): you are calling copy_to_user (which can sleep) with the spin lock held.

    • 0