Date: Tue, 6 Mar 2001 20:23:03 +0200 (SAT) From: John Hay <jhay@icomtek.csir.co.za> To: bmilekic@technokratis.com (Bosko Milekic) Cc: itojun@iijlab.net, freebsd-net@FreeBSD.ORG Subject: Re: kernel: nd6_storelladdr failed, mbuf leak Message-ID: <200103061823.f26IN3064621@zibbi.icomtek.csir.co.za> In-Reply-To: <005501c0a660$89fc2bd0$becbca18@jehovah> from Bosko Milekic at "Mar 6, 2001 12:11:52 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > >> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103061823.f26IN3064621>