Date: Fri, 08 Nov 2019 21:44:03 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 241808] bhyve e1000 broken after r354288 Message-ID: <bug-241808-27103-GRU1i4cygg@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-241808-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-241808-27103@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241808 Vincenzo Maffione <vmaffione@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #1 from Vincenzo Maffione <vmaffione@FreeBSD.org> --- Very interesting, thanks for catching it. I think the real problem here (even before r354288) is that nothing prevents a call to kevent(fd, EV_ENABLE) to happen before kevent(fd, EVADD) is called, as you are reporting. On mevent_add() and mevent_update(), mevent_notify() is called to wakeup the I/O thread, that will call kevent(changelist) to update the kernel. A race condition is possible where the client calls mevent_add() and mevent_update(EV_ENABLE) before the I/O thread has the chance to wake up and calls mevent_build()+kevent(changelist), which is exactly what happens in your case. r354288 only makes this race condition more likely (this explains why I did not catch the bug on my machine when I tested e1000). Your fix makes the race condition less likely, but I think it's still there. I tried to rework and simplify mevent.c to make sure EV_ADD is always called before EV_ENABLE or EV_DISABLE. Let me know what you think about that: https://reviews.freebsd.org/D22286 -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-241808-27103-GRU1i4cygg>