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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241808 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 prevent= s 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 y= our 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 --=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-241808-27103-GRU1i4cygg>