Deadlock in the routing code

[Julian Elischer]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"