From owner-freebsd-net@FreeBSD.ORG  Thu Dec 13 13:39:09 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 5B61C16A418;
	Thu, 13 Dec 2007 13:39:09 +0000 (UTC) (envelope-from mux@freebsd.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.freebsd.org (Postfix) with ESMTP id 3C81613C4E3;
	Thu, 13 Dec 2007 13:39:08 +0000 (UTC) (envelope-from mux@freebsd.org)
Received: by elvis.mu.org (Postfix, from userid 1920)
	id 4E1341A4D7C; Thu, 13 Dec 2007 05:38:17 -0800 (PST)
Date: Thu, 13 Dec 2007 14:38:17 +0100
From: Maxime Henrion <mux@FreeBSD.org>
To: glebius@FreeBSD.org
Message-ID: <20071213133817.GC71713@elvis.mu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Cc: net@FreeBSD.org
Subject: Deadlock in the routing code
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2007 13:39:09 -0000

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