Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Jan 2014 10:34 +0100
From:      Alexandre Martins <alexandre.martins@netasq.com>
To:        Eric Joyner <ricera10@gmail.com>
Cc:        pyunyh@gmail.com, damien.deville@netasq.com, freebsd-current@freebsd.org, fabien.thomas@netasq.com, Gleb Smirnoff <glebius@freebsd.org>, Jack F Vogel <jfv@freebsd.org>
Subject:   Re: FreeBSD 10-RC4: Got crash in igb driver
Message-ID:  <2055921.6VO2ozmCaJ@pc-alex>
In-Reply-To: <CA%2Bb0zg-tpzLve_mkuq7%2BfG1f-A9DgeKf8vqBpbrAK33s5Y%2B2fQ@mail.gmail.com>
References:  <48005124.ny58tnLn4d@pc-alex> <20140113021018.GA3500@michelle.cdnetworks.com> <CA%2Bb0zg-tpzLve_mkuq7%2BfG1f-A9DgeKf8vqBpbrAK33s5Y%2B2fQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--nextPart3445562.qoCPSgfVDr
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

I have some compillation issues :

../../../dev/e1000/if_igb.c: In function 'igb_mq_start_locked':
../../../dev/e1000/if_igb.c:3936: warning: 'poff' may be used uninitial=
ized in=20
this function
../../../dev/e1000/if_igb.c:3936: note: 'poff' was declared here
../../../dev/e1000/if_igb.c:3936: warning: 'ip_hlen' may be used uninit=
ialized=20
in this function
../../../dev/e1000/if_igb.c:3936: note: 'ip_hlen' was declared here


But this fix the crash.

However, I have now a copy made of all ipv6 forwarded packet in=20
igb_pullup_headers.

It will be nice to m_free the copy of the packet made in ip6_forward be=
fore=20
calling nd6_output function. It will put back the packet writable and a=
void=20
(in most cases) the copy.

I have no time this week to check performance of this new driver versio=
n. I'll=20
try to make that Monday.

Thank you for this fix

Le mardi 14 janvier 2014 14:22:43 Eric Joyner a =E9crit :
> All,
>=20
> I work with Jack on FreeBSD network drivers, and we have a patch that=
 we
> think might fix this problem. It re-implements the header pull-up cod=
e that
> was in the driver pre-2.4.0, but with IPv6 support. Alexandre, could =
you
> apply this patch to the igb version in HEAD and try it out on your ne=
twork?
> We can't replicate your setup here.
>=20
> If it solves your problem, then the next step would be to port the pa=
tch to
> the ixgbe driver since, as Yonghyeon noted, it looks like that driver=
 will
> encounter the same problem. We could then modify em to add IPv6 offlo=
ad
> support as well.
>=20
> Thanks,
>=20
> ---
> - Eric Joyner
>=20
> On Fri, Jan 10, 2014 at 02:35:29PM +0400, Gleb Smirnoff wrote:
> >   Yonghyeon,
> >=20
> > On Fri, Jan 10, 2014 at 10:21:14AM +0900, Yonghyeon PYUN wrote:
> > Y> > I experience some troubles with the igb device driver on FreeB=
SD
>=20
> 10-RC4.
>=20
> > Y> >
> > Y> > The kernel make a pagefault in the igb_tx_ctx_setup function w=
hen
>=20
> accessing to
>=20
> > Y> > a IPv6 header.
> > Y> >
> > Y> > The network configuration is the following:
> > Y> >  - box acting as an IPv6 router
> > Y> >  - one interface with an IPv6 (igb0)
> > Y> >  - another interface with a vlan, and IPv6 on it (vlan0 on igb=
1)
> > Y> >
> > Y> > Vlan Hardware tagging is set on both interfaces.
> > Y> >
> > Y> > The packet that cause the crash come from igb0 and go to vlan0=
.
> > Y> >
> > Y> > After investigation, i see that the mbuf is split in two. The =
first
>=20
> one carry
>=20
> > Y> > the ethernet header, the second, the IPv6 header and data payl=
oad.
> > Y> >
> > Y> > The split is due to the "m_copy" done in ip6_forward, that mak=
e the
>=20
> mbuf not
>=20
> > Y> > writable and the "M_PREPEND" in ether_output that insert the n=
ew
>=20
> mbuf before
>=20
> > Y> > the original one.
> > Y> >
> > Y> > The kernel crashes only if the newly allocated mbuf is at the =
end of
>=20
> a memory
>=20
> > Y> > page, and no page is available after this one. So, it's extrem=
ly
>=20
> rare.
>=20
> > Y> >
> > Y> > I inserted a "KASSERT" into the function (see attached patch) =
to
>=20
> check this
>=20
> > Y> > behavior, and it raises on every IPv6 forwarded packet to the =
vlan.
>=20
> The
>=20
> > Y> > problem disapear if i remove hardware tagging.
> > Y> >
> > Y> > In the commit 256200, i see that pullups has been removed. May=
 it be
>=20
> related ?
>=20
> > Y>
> > Y> I think I introduced the header parsing code to meet controller
> > Y> requirement in em(4) and Jack borrowed that code in the past but=
 it
> > Y> seems it was removed in r256200.  It seems igb_tx_ctx_setup()
> > Y> assumes it can access ethernet/IP/TCP/UDP headers in the first m=
buf
> > Y> of the chain.
> > Y> This looks wrong to me.
> >=20
> > Can you please restore the important code in head ASAP? Although cr=
ashes
>=20
> happen
>=20
> > only when the mbuf is last in a page and page isn't mapped, we read=

>=20
> thrash from
>=20
> > next allocation on almost every packet.
>=20
> It seems other Intel ethernet drivers except em(4) have similar
> issues.  I didn't check recent Intel controllers/drivers for long
> time so I don't know details on hardware requirements of
> offloading.
> Since Jack is very responsive and has hardwares to verify, he would
> be more appropriate person to handle these issues.
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=
.org"
--=20
Alexandre Martins
NETASQ -- We secure IT


--nextPart3445562.qoCPSgfVDr
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIErzCCBKsw
ggOToAMCAQICCnDGsUgWa/KQbDQwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkZSMQ0wCwYD
VQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0g
U2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MB4XDTEzMDIxNTE1NDk1N1oXDTE0MDIxNTE1NDk1N1owgdoxCzAJBgNVBAYT
AkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMl
TkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNRIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MRowGAYDVQQDExFBbGV4YW5kcmUgTUFSVElOUzErMCkGCSqG
SIb3DQEJARYcYWxleGFuZHJlLm1hcnRpbnNAbmV0YXNxLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAL4/gp0+01ma1Hi1C9Zw7TY8nZPJTmB3HG5eX1e062tMm+0CrNcDwfMwmF8w
g47zuFzkzTYy/d6/waoHbbCLsj1AM2kRQcWfuqglpgnSu7FdnIAE0dSAOS9Ni0uWDsFhRr3UUHq5
qnDzQXOrPXRMzMz1W8nqiyqXYfykrDrq0sjzaIj20BYA/6AlDSWs+XKid1EM3wOe40Kyl+1HWLsA
MuY9CpQdAkQh4rJb6Sbgx57DXJ3INCSWjzZWYK0KAE0JF8XhP5zLGcvHI5Atm7gN8WiMZ+DFRM2z
HIOlZ6zhp1VHSSbs+c64UJtGgt+cq7QvuyaIoqBP6rDHsLMPbjNR0w8CAwEAAaOBuTCBtjAdBgNV
HQ4EFgQUyiEDfxLvYJqY+A8btt9sZFYPejYwHwYDVR0jBBgwFoAUJyrrHdlE2joXc2oJICDJJaj5
f7IwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCA+gwJwYDVR0RBCAwHoEcYWxleGFuZHJlLm1hcnRp
bnNAbmV0YXNxLmNvbTARBglghkgBhvhCAQEEBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG
AQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQCaSZdSJKRujYP6KnfKcyYYlNNqRdIyQm16o4BIIeGG
qxQGxAO/dzcQziNVQcE+G8RHTcuivayhOX/NRhIlYxyvTN+wWAbC5NQuul4eQzGrz4OxWfrfpm9S
DnDbLfHf1qdjyvFkTM8Wgq21/oExphasFHdOxi/txN4099Be/BZpV8Fpqa0dKEirG2Wa3KfEn85A
WaKnNs/k3x95gr/eeTt1NdlT7OqVYqnUdUlRmQVNvEi29wIQbfYi2WeZIGlpNh0PBthWdBaXzMKU
U/pfjIzZhyP8E4ghUKz4uvmpA901Qj9LEhSYqOKWALRNOk/dCcNd0LV8S54te/vsFkDTHWvlMYIC
UjCCAk4CAQEwgaAwgZExCzAJBgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxs
ZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rp
dml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AgpwxrFIFmvykGw0
MAkGBSsOAwIaBQCggYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTQwMTE1MDkzNDAwWjAjBgkqhkiG9w0BCQQxFgQUheBUec8907G+ENYlrnH3xeyvLFUwKAYJKoZI
hvcNAQkPMRswGTALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEBBQAEggEADeaz
rdSbmdtHNaN4LsIxDDU3Jl0RL4SpEeH+MbuoYWggy1uPmn/t3PL5OEIrIq02/cxlXugXmQCRVJbU
vX5+XMfGoI2eToEs1jIy78XmFfgJvBJSr+52ONtnUfrujhA+wr/JoTYeDeCz7kmJnY1u+0c+igjO
a9NnfW+Vx2TEAW5ej0IJipFRJXbZrPAzuin/3arI+7QRaeegcPKXfShPZDZtwRz6q6xEuK8yjI4R
d2ZsKbS7HmiwdP81tsci4quFuLc7OQclcLJ9otuDUoM4G054vDHO89ylKEMBU59SUsFEf6xj9Qnu
4UlrAjTc4LpMPMnOB896by2OzXwCmFEmigAAAAAAAA==

--nextPart3445562.qoCPSgfVDr--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2055921.6VO2ozmCaJ>