Deadlock in the routing code

Maxime Henrion mux at
Thu Dec 13 05:39:09 PST 2007

Replying to myself on this one, sorry about that.

I said in my previous mail that I didn't know yet what process was
holding the lock of the rtentry that the routed process is dealing
with in rt_setgate(), and I just could verify that it is held by
the swi1: net thread.

So, in a nutshell:

- The routed process does its business on the routing socket, that ends up
  calling rt_setgate().  While in rt_setgate() it drops the lock on its
  rtentry in order to call rtalloc1().  At this point, the routed
  process hold the gateway route (rtalloc1() returns it locked), and it
  now tries to re-lock the original rtentry.
- At the same time, the swi net thread calls arpresolve() which ends up
  calling rt_check().  Then rt_check() locks the rtentry, and tries to
  lock the gateway route.

A classical case of deadlock with mutexes because of different locking
order.  Now, it's not obvious to me how to fix it :-).


More information about the freebsd-net mailing list