Date: Mon, 27 Jul 2015 21:58:51 +0900 From: Yonghyeon PYUN <pyunyh@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, Sean Bruno <sbruno@freebsd.org> Subject: Re: E1000 mbuf leaks Message-ID: <20150727125850.GA986@michelle.fasterthan.com> In-Reply-To: <55B60FC8.2020003@selasky.org> References: <55B60FC8.2020003@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 27, 2015 at 01:02:32PM +0200, Hans Petter Selasky wrote: > Hi, > > I'm currently doing some busdma work, and possibly stepped over some > driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf > chain is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" > for that error code or is there a possible memory leak in all E1000 > drivers? See attached patch. I don't think it's an mbuf leak since lem(4) just prepend the mbuf to the if sendq(driver will retry it later). But I think your patch looks more correct in bus_dma(9) perspective. If bus_dmamap_load_mbuf_sg(9) returned an error except EFBIG, it would be correct for lem(4) to free the mbuf chains rather than restarting the bus_dmamap_load_mbuf_sg(9) later which shall fail again with ENOMEM.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150727125850.GA986>