Deadlock in the routing code
Maxime Henrion
mux at FreeBSD.org
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 :-).
Maxime
More information about the freebsd-net
mailing list