Date: Wed, 31 Jul 2019 15:50:24 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 239118] in ESXi: Panic in ether_output_frame Message-ID: <bug-239118-27103-4rmla9w4nH@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-239118-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-239118-27103@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=3D239118 --- Comment #9 from Patrick Kelsey <pkelsey@freebsd.org> --- (In reply to Marius Strobl from comment #7) > I'd say that with an INTx-type interrupt or a single MSI vector, i. e. all > the "legacy" interrupt support iflib is about, there's just no other way > than to operate in combined RXTX mode (as opposed to multiple MSI-X vecto= rs > which can be associated to either RX or TX on a per-vector basis). > Thus, - as actually already written in my private e-mail to pkelsey@ and = the > submitter on June 25th - I fully agree with markj@ analysis that > vmxnet3_isc_txd_credits_update() currently isn't reentrant as well as with > his fix (I'd probably code it to be more in line with the index updating = in > vmxnet3_isc_rxd_available(), though). > However, as I also already wrote in said e-mail, on top of that it isn't > obvious to me that it's safe to update txc->vxcr_next and txc->vxcr_gen > non-atomically/lockless since r343291 dropped the locking around these > operations. Marius, you are missing the point, which is that you have failed to consider the case of drivers that don't use TX interrupts at all, of which the vmx driver is an example. Drivers that don't use TX interrupts still only have= one queue-related interrupt in legacy mode. By assuming that all drivers want to (i.e., are designed to) do TX processi= ng during their RX interrupts, even when those drivers have clearly indicated = they are not implementing TX mode or RXTX mode hardware interrupts in their interface to iflib, you are breaking drivers such as vmx. I fully agree that vmxnet3_isc_txd_credits_update() is not re-entrant - bec= ause it was explicitly designed on the basis that it does not have to be. Anyon= e of course is welcome to redesign the vmx driver under changed design assumptio= ns, and I would caution anyone going down that path that the whole vmx driver should be re-examined in this case. I think it would be better to fix the iflib legacy mode interrupt setup so = it does not assume it can invoke TX processing from the RX interrupt unless the driver has indicated it is using TXRX mode, or perhaps indicated that it is using hardware-based TX interrupts. --=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-239118-27103-4rmla9w4nH>