Date: Tue, 07 Jan 2020 12:50:48 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 243126] Assertion fl->ifl_cidx == cidx failed at /usr/src/sys/net/iflib.c:2531 Message-ID: <bug-243126-7501-xVoIS4fTuq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-243126-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-243126-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243126 Andriy Gapon <avg@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #3 from Andriy Gapon <avg@FreeBSD.org> --- I wonder if irf_idx can "jump ahead" of ifl_cidx because of a skipped zero-length packet? Hmm, it seems like it could be the case. Given the current value of iri_cidx/ifr_cq_cidx, I examined three descripto= rs before that index: (kgdb) p $19.vxcr_u.rxcd[476] $21 =3D {rxd_idx =3D 142, pad1 =3D 0, eop =3D 1, sop =3D 1, qid =3D 0, rss_= type =3D 2, no_csum =3D 0, pad2 =3D 0, rss_hash =3D 600473664, len =3D 1514, error =3D = 0, vlan =3D 0, vtag =3D 0, csum =3D 0, csum_ok =3D 1, udp =3D 0, tcp =3D 1, ipcsum_ok =3D = 1, ipv6 =3D 0,=20 ipv4 =3D 1, fragment =3D 0, fcs =3D 0, type =3D 3, gen =3D 1} (kgdb) p $19.vxcr_u.rxcd[475] $22 =3D {rxd_idx =3D 141, pad1 =3D 0, eop =3D 1, sop =3D 1, qid =3D 0, rss_= type =3D 0, no_csum =3D 0, pad2 =3D 0, rss_hash =3D 0, len =3D 0, error =3D 0, vlan =3D= 0, vtag =3D 0, csum =3D 0, csum_ok =3D 0, udp =3D 0, tcp =3D 0, ipcsum_ok =3D 0, ipv6 =3D = 0, ipv4 =3D 0,=20 fragment =3D 0, fcs =3D 0, type =3D 3, gen =3D 1} (kgdb) p $19.vxcr_u.rxcd[474] $23 =3D {rxd_idx =3D 140, pad1 =3D 0, eop =3D 1, sop =3D 1, qid =3D 0, rss_= type =3D 2, no_csum =3D 0, pad2 =3D 0, rss_hash =3D 600473664, len =3D 66, error =3D 0,= vlan =3D 0, vtag =3D 0, csum =3D 0, csum_ok =3D 1, udp =3D 0, tcp =3D 1, ipcsum_ok =3D = 1, ipv6 =3D 0,=20 ipv4 =3D 1, fragment =3D 0, fcs =3D 0, type =3D 3, gen =3D 1} The descriptor at 476 with rxd_idx =3D 142 seems like the current packet. And the previous descriptor at 475 with rxd_idx =3D 141 is a zero-length pa= cket: eop =3D 1, sop =3D 1, len =3D 0. The packet before it is a normal packet again: eop =3D 1, sop =3D 1, len = =3D 66. Now, how to fix the problem? I see two ways: - a driver can notify iflib of a zero length packet (via a new callback), so that iflib can skip the corresponding entry in the appropriate free list - rxd_frag_to_sd() can skip through fl entries until ifl_cidx becomes equal= to irf_idx --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-243126-7501-xVoIS4fTuq>