Hello, I have a stupid question regarding which variant of spin_lock to use throughout the network stack, and inside RX handlers specifically.
It's my understanding that skbuffs are normally passed into the stack from soft IRQ context if the device is using NAPI, and hard IRQ context if it's not using NAPI (and I guess process context too if the driver does it's own workqueue thing). So, that means that handlers registered with netdev_rx_handler_register may end up being called from any context. However, the RX handler in the macvlan code calls ip_check_defrag, which could eventually lead to a call to ip_defrag, which ends up taking a regular spin_lock around the call to ip_frag_queue. Is this a risk of deadlock, and if not, why? What if you're running a system with one CPU and a packet fragment arrives on a NAPI interface, then, while the spin_lock is held, another fragment somehow arrives on another interface which does its processing in hard IRQ context? -- Jacob S. Moroni m...@jakemoroni.com
