> >
> > >> > > 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 -- [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
