From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 05:03:44 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 7E1421065674; Tue, 10 Jul 2012 05:03:44 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id D1B888FC1D; Tue, 10 Jul 2012 05:03:43 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q6A53akx098164; Tue, 10 Jul 2012 12:03:37 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FFBB7A8.90201@rdtc.ru> Date: Tue, 10 Jul 2012 12:03:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ryan Stone References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: bzeeb-lists@lists.zabbadoz.net, Przemyslaw Frasunek , Mike Tancsa , freebsd-net@freebsd.org Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 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 Jul 2012 05:03:44 -0000 10.07.2012 03:25, Ryan Stone пишет: > On Mon, Jul 9, 2012 at 4:12 AM, Gleb Smirnoff wrote: >> This looks very much related to a known race in ARP code. >> >> See this email and related thread: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031865.html >> >> Ryan didn't check in any patches since, and I failed to follow on this >> problem due to ENOTIME. >> >> I've added Ryan to Cc. Ryan, what's the status of the problem at your >> side? Did you come to any solution? > > Unfortunately I was never able to come to a satisfactory solution. As > I recall, in the end I ran headlong into problems with making the > locking sane. The big problem was with arpresolve. At one point it > calls callout_reset to schedule the LLE's la_timer. In my patch this > would have to be done with a write lock help on the afdata lock. > However, this acquisition would have to be done before taking the > LLE_LOCK to prevent a LOR, and in the end you conclude that you have > to take a write lock on the ifnet's afdata lock for every packet that > goes through arpresolve, which was a non-starter. That's the point > that I reached before I got distracted by other things at $WORK. > > As I recall, the in6 case was even worse, as the in6 equivalent of > arptimer is significantly more complicated and likes to do crazy > things like dropping locks. It seems, Przemyslaw Frasunek uses proxyarp? I have no such problems but I do not use proxyarp. Could you get rid of it, Przemyslaw? Eugene Grosbein