Date: Thu, 16 Sep 2010 08:27:30 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Marcin Cieslak <saper@saper.info> Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch Message-ID: <201009160827.30410.jhb@freebsd.org> In-Reply-To: <slrni92gae.177v.saper@saper.info> References: <slrnht8djj.1tsh.saper@saper.info> <201009151749.45038.jhb@freebsd.org> <slrni92gae.177v.saper@saper.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, September 15, 2010 5:57:34 pm Marcin Cieslak wrote: > Dnia 15.09.2010 John Baldwin <jhb@freebsd.org> napisa=C5=82/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. > >>=20 > >> Looks like it's a race condition (same in tun(4) and tap(4)),=20 > >> the following patch seems to address the issue: > > > > This is a good find. I actually went through these drivers a bit furth= er and=20 > > have a bit of a larger patch to extend the locking some. Would you car= e to=20 > > test it? >=20 > Sure, I am installing it right now (for if_tun right now). >=20 > There are also a LORs during tunclose (I always get one of them when clos= ing the > tunnel): Hmm, this looks to be in the if_purgeaddrs() routine itself and not specific to tun/tap. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009160827.30410.jhb>