Maxime Henrion wrote:
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 :-).
On failure to re-lock, the routed call to rt_setgate should completely
abort and restart from scratch, releasing all locks it has on the way out.
Maxime
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
