[Bug 240608] if_vmx(4): iflib - Panic with INVARIANTS: Memory modified after free (12.1-pre-QA)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240608

--- Comment #15 from Patrick Kelsey <pkelsey at 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 driver
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 following. 
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 packet
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 that
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/free
list mechanism and how the vmx driver interacts with it in order to determine
whether there is a bug in the vmx driver, the iflib implementation has shifted
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.