From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 06:54:39 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FD971065670 for ; Tue, 10 Apr 2012 06:54:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id E9E818FC15 for ; Tue, 10 Apr 2012 06:54:38 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3A6sWt4034991; Tue, 10 Apr 2012 10:54:32 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3A6sWMR034990; Tue, 10 Apr 2012 10:54:32 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 10 Apr 2012 10:54:32 +0400 From: Gleb Smirnoff To: Ryan Stone Message-ID: <20120410065432.GJ9391@glebius.int.ru> References: <201203090930.q299UCPX057950@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: kern/165863 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 06:54:39 -0000 Thanks, Ryan! On Thu, Mar 29, 2012 at 05:59:38PM -0400, Ryan Stone wrote: R> Ok, I think that I have an approach that will work. This is heavily R> based off of glebius' proposal. The big difference is that instead of R> initializing the arptimer callout with the ll_entry's lock, I R> initialize it with the if_afdata_lock. This eliminates the LOR R> problem in arptimer. It also nicely prevents any races between R> arptimer and in_lltable_prefix_free. Either arptimer will run and R> ensure that prefix_free can never see an entry that arptimer is in the R> process of destroying, or prefix_free will stop the callout before R> arptimer gets a chance to start. R> R> I'll admit that it feels a bit dirty to be doing anything if the ifp R> at this level, but I'd argue that is an artifact of using a lock in R> the ifp to protect the lltable. R> R> The patch below is not yet complete; it doesn't fix the IPv6 case. R> IPv6 is looking much trickier as when an NDP entry is timed out R> nd6_free() will drop the LLE_WLOCK, acquire the IF_AFDATA_LOCK and R> then re-acquire the LLE_WLOCK. It's not immediately clear to me what R> the best way to handle the race between in6_lltable_prefix_free and R> nd6_llinfo_timer is. Holding the afdata_lock across all of R> nd6_llinfo_timer feels like overkill. R> R> Any comments on this approach? Am I going in the wrong direction? Looks okay from my viewpoint. Have you stress tested it? My snap patch definitely had problems, AFAIR. If this patch fixes panics observed by kern/165863 and passes stress testing, then it should be committed ASAP, and shouldn't depend on IPv6 part. -- Totus tuus, Glebius.