From owner-freebsd-net Tue Mar 6 10:25:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 7823637B719 for ; Tue, 6 Mar 2001 10:25:12 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f26IN3064621; Tue, 6 Mar 2001 20:23:03 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200103061823.f26IN3064621@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak In-Reply-To: <005501c0a660$89fc2bd0$becbca18@jehovah> from Bosko Milekic at "Mar 6, 2001 12:11:52 pm" To: bmilekic@technokratis.com (Bosko Milekic) Date: Tue, 6 Mar 2001 20:23:03 +0200 (SAT) Cc: itojun@iijlab.net, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > >> > > I then noticed that "... kernel: nd6_storelladdr failed" gets > logged > > >> > > often and after a while all mbufs are used. It turned out > that in > > >> > > sys/net/if_ethersubr.c in ether_output() when > nd6_storelladdr() > > >> > fails, > > >> > > it does a return(0) and does not free the mbuf. I > checked -current > > >> > > and it is still like that. > > > > will correct it. thanks for reporting. > > > > itojun > > This behavior is absolutely horrible. What ought to be fixed, if > ether_input() is supposed to be freeing the passed in mbuf, is that > ether_input() should instead accept a pointer to a pointer so that > after it frees the mbuf it can NULL out the initial pointer. Because > of promoting similar existing coding practises in this area of the > code, what we're seeing is ether_input() effectively returning an mbuf > to the free list while the caller still holds a live pointer to that > mbuf. > Uhmm, we are talking about ether_output(), not ether_input(), but their behaviour is similar. I don't think any changes in the api is necessary. It has been like that from when I came in touch with 386bsd. You would need to change all the drivers and all the network stacks and also all the similar functions like fddi_input() and fddi_output(), etc. Both functions are called and handed a mbuf with the idea that it (ether_input() or ether_output()) should "send" it on as well as possible, normally it will be to add it to the correct interface or network stack queue. Any function calling ether_input() or ether_output() and expecting to be able to use that mbuf afterwards was written for a non BSD OS. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message