Re: FreeBSD 10-RC4: Got crash in igb driver

From: Yonghyeon PYUN <pyunyh_at_gmail.com>
Date: Fri, 10 Jan 2014 10:21:14 +0900
On Thu, Jan 09, 2014 at 04:06:09PM +0100, Alexandre Martins wrote:
> Dear,
> 
> I experience some troubles with the igb device driver on FreeBSD 10-RC4.
> 
> The kernel make a pagefault in the igb_tx_ctx_setup function when accessing to 
> a IPv6 header.
> 
> The network configuration is the following:
>  - box acting as an IPv6 router
>  - one interface with an IPv6 (igb0)
>  - another interface with a vlan, and IPv6 on it (vlan0 on igb1)
> 
> Vlan Hardware tagging is set on both interfaces.
> 
> The packet that cause the crash come from igb0 and go to vlan0.
> 
> After investigation, i see that the mbuf is split in two. The first one carry 
> the ethernet header, the second, the IPv6 header and data payload.
> 
> The split is due to the "m_copy" done in ip6_forward, that make the mbuf not 
> writable and the "M_PREPEND" in ether_output that insert the new mbuf before 
> the original one.
> 
> The kernel crashes only if the newly allocated mbuf is at the end of a memory 
> page, and no page is available after this one. So, it's extremly rare.
> 
> I inserted a "KASSERT" into the function (see attached patch) to check this 
> behavior, and it raises on every IPv6 forwarded packet to the vlan. The 
> problem disapear if i remove hardware tagging.
> 
> In the commit 256200, i see that pullups has been removed. May it be related ?
> 

I think I introduced the header parsing code to meet controller
requirement in em(4) and Jack borrowed that code in the past but it
seems it was removed in r256200.  It seems igb_tx_ctx_setup()
assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf
of the chain.
This looks wrong to me.

> Can you confirm the problem ?
> 

Probably Jack can tell more about change made in r256200.  It's not
easy for me to verify correctness of igb(4) at this moment.

> Best regards
> 
> -- 
> Alexandre Martins
> NETASQ -- We secure IT
Received on Fri Jan 10 2014 - 00:21:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:46 UTC