From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 13:02:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A21FB106564A for ; Thu, 16 Sep 2010 13:02:34 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5288FC0C for ; Thu, 16 Sep 2010 13:02:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OwE6i-00015k-Qu for freebsd-current@freebsd.org; Thu, 16 Sep 2010 15:02:32 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2010 15:02:32 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2010 15:02:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Thu, 16 Sep 2010 13:02:23 +0000 (UTC) Organization: http://saper.info Lines: 17 Message-ID: References: <201009151749.45038.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Thu, 16 Sep 2010 14:00:01 +0000 Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 13:02:34 -0000 Dnia 15.09.2010 John Baldwin napisał/a: > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: >> Output queue of tun(4) gets full after some time when sending lots of data. >> I have been observing this on -CURRENT at least since March this year. >> >> Looks like it's a race condition (same in tun(4) and tap(4)), >> the following patch seems to address the issue: > > This is a good find. I actually went through these drivers a bit further and > have a bit of a larger patch to extend the locking some. Would you care to > test it? Do you think those drivers could be taken out of Giant after this change? I think that networking code path (via if_start etc.) is not using Giant at all, only cdevsw routines are. Am I right? //Marcin