From owner-cvs-src@FreeBSD.ORG Mon Jun 5 21:26:18 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0069716CEF4; Mon, 5 Jun 2006 21:22:06 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFE6D43D46; Mon, 5 Jun 2006 21:22:06 +0000 (GMT) (envelope-from qingli@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id k55LKLsF056254; Mon, 5 Jun 2006 21:20:21 GMT (envelope-from qingli@repoman.freebsd.org) Received: (from qingli@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id k55LKLrh056253; Mon, 5 Jun 2006 21:20:21 GMT (envelope-from qingli) Message-Id: <200606052120.k55LKLrh056253@repoman.freebsd.org> From: Qing Li Date: Mon, 5 Jun 2006 21:20:21 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/net route.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 21:26:32 -0000 qingli 2006-06-05 21:20:21 UTC FreeBSD src repository Modified files: sys/net route.c Log: Assuming the interface has an address of x.x.x.195, a mask of 255.255.255.0, and a default route with gateway x.x.x.1. Now if the address mask is changed to something more specific, e.g., 255.255.255.128, then after the mask change the default gateway is no longer reachable. Since the default route is still present in the routing table, when the output code tries to resolve the address of the default gateway in function rt_check(), again, the default route will be returned by rtalloc1(). Because the lock is currently held on the rtentry structure, one more attempt to hold the lock will trigger a crash due to "lock recursed on non-recursive mutex ..." This is a general problem. The fix checks for the above condition so that an existing route entry is not mistaken for a new cloned route. Approriately, an ENETUNREACH error is returned back to the caller Approved by: andre Revision Changes Path 1.117 +6 -0 src/sys/net/route.c