Date: Thu, 16 Jan 2020 14:21:39 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 240608] if_vmx(4): iflib - Panic with INVARIANTS: Memory modified after free (12.1-pre-QA) Message-ID: <bug-240608-7501-elfDweo8eu@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-240608-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-240608-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=3D240608 --- Comment #15 from Patrick Kelsey <pkelsey@freebsd.org> --- (In reply to Andriy Gapon from comment #11) Regarding ignoring rxd->error in the iflib driver: Just as a piece of background information, one thing that is true is that rxd->error can only be set when rx->eop is set (according to reference driv= er sources). In the error case, we still need iflib to do all of the related completion queue/free list processing for descriptors from sop to eop, but we also have knowledge that the packet is 'bad'. The current treatment of the error indication case is based on the followin= g.=20 There is no facility in the iflib interface (now, or when this driver was written) to indicate this case to iflib. So the vmx driver submits the pac= ket anyway, under the reasoning that it is already possible to receive damaged packets from the network (that pass the checksum checks and so on). It is perhaps not strictly optimal to not take advantage of the early knowledge t= hat the packet is bad, but this does not introduce a new possible condition for= the network stack, and this is a rare event. Considering this again, this approach does rely on the virtual device to not provide damaged fragment length indicators (meaning something greater than = the configured buffer size) in the error case, and perhaps we should not trust = it to do so, in which case the minimal change to what we currently have would = be to check rxd->error, and if set, consider the length of the eop fragment to= be zero. iflib probably needs an audit on all of the cases of receiving zero length fragments. I may have some time next week to re-analyze the current iflib descriptor/f= ree list mechanism and how the vmx driver interacts with it in order to determi= ne whether there is a bug in the vmx driver, the iflib implementation has shif= ted since the vmx driver was written in a way that breaks the vmx driver, or everything looks OK and there is some other root cause here. --=20 You are receiving this mail because: You are on the CC list for the bug. 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-240608-7501-elfDweo8eu>