Date: Tue, 23 Nov 2004 10:00:55 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: net@FreeBSD.org Subject: Running into an mbuf leak with bridging and tap Message-ID: <Pine.NEB.3.96L.1041123093708.66539K-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
I'm running an ethernet over TCP bridge using a combination of the native ethernet bridge support and the tap driver. Basically, a daemon sits on /dev/tapX and bridges ethernet frames using a small header over a TCP connection. The bridge support is loaded as a kld, as is the tap support, and both modules remain resident from then on. After a couple of days, perhaps triggered by the connection going up and down and leaving bridging turned on even when nothing is listening on the tap device, the endpoints will run out of mbufs: 26707 mbufs in use 25453/25600 mbuf clusters in use (current/max) 0/3/6656 sfbufs in use (current/peak/max) 57582 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Under normal circumstances (i.e., without tap and ethernet bridging on), this doesn't happen, suggesting that maybe there's a leak in the bridging code or tap code. I've now seen this with three boxes, a blend of UP and SMP. I haven't yet had a chance to sit down with a debugging kernel. Has anyone else seen anything like this? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041123093708.66539K-100000>