em(4) updated to version 7.1.8

Jack Vogel jfvogel at gmail.com
Mon Nov 29 19:50:26 UTC 2010


True, there is no check,  I do not see a way in which the mbuf
pointer should be NULL, however, perhaps I should change things
to follow what the igb driver does, always checking for NULL and
freeing the existing mbuf to allow em_refresh_mbufs() to repop.

If you say you have had panics then there must be a path to have
it NULL.

Jack


On Mon, Nov 29, 2010 at 11:23 AM, Eugene Grosbein <eugen at eg.sd.rdtc.ru>wrote:

> On Mon, Nov 29, 2010 at 11:10:22AM -0800, Jack Vogel wrote:
>
> > Not sure what code you created this from, but its not the new driver,
>
> Yes, that's for previous version and that's what keeps my production
> servers from panicing.
>
> > things have been reorganized and I do not believe this issue exists.
> > Please test with the latest.
>
> I'd rather not risk. Here is the same check for today's RELENG_8 driver.
> Please, please take a look. After several days of nearly gigabit load
> it has already happened m_head was NULL here, in previous version.
> Can it be possible in current version?
> There is still no check before dereferencing.
>
> --- if_em.c.orig        2010-11-30 01:16:17.000000000 +0600
> +++ if_em.c     2010-11-30 01:19:09.000000000 +0600
> @@ -4321,10 +4321,12 @@
>
>        /* Reset state, keep loaded DMA map and reuse */
>        m = rbuf->m_head;
> +       if(m) {
>        m->m_len = m->m_pkthdr.len = adapter->rx_mbuf_sz;
>        m->m_flags |= M_PKTHDR;
>        m->m_data = m->m_ext.ext_buf;
>        m->m_next = NULL;
> +       }
>
>        return;
>  }
>


More information about the freebsd-net mailing list