From owner-freebsd-current@FreeBSD.ORG Mon Oct 4 21:23:29 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 92C50106566C for ; Mon, 4 Oct 2010 21:23:29 +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 4C0868FC0C for ; Mon, 4 Oct 2010 21:23:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P2sVM-0001Vq-5i for freebsd-current@freebsd.org; Mon, 04 Oct 2010 23:23:28 +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 ; Mon, 04 Oct 2010 23:23:28 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Oct 2010 23:23:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Mon, 4 Oct 2010 21:23:19 +0000 (UTC) Organization: http://saper.info Lines: 27 Message-ID: References: <201009151749.45038.jhb@freebsd.org> <201009170854.56516.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: Mon, 04 Oct 2010 21:26:16 +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: Mon, 04 Oct 2010 21:23:29 -0000 >> John Baldwin wrote: > On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote: >> 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? > > Oh, yes. I've updated the patch to remove D_NEEDGIANT. I just want to report back that may tun(4) tunnel has been rock-solid since I applied the patch. Didn't have a chance to test tap(4) and it won't happen for another week or so - I hope somebody else jumps in the meantime. Thank you! //Marcin