Date: Thu, 27 Dec 2018 11:25:47 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 234442] libnetgraph race condition Message-ID: <bug-234442-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234442 Bug ID: 234442 Summary: libnetgraph race condition Product: Base System Version: 11.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: net@FreeBSD.org Reporter: eugen@freebsd.org CC: avg@FreeBSD.org, glebius@FreeBSD.org, kib@FreeBSD.org, mav@FreeBSD.org Created attachment 200557 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D200557&action= =3Dedit fight race with mutex Hi! lib/libnetgraph/msg.c defines static int gMsgId and public functions NgSendMsg() and NgSendAsciiMsg() that both increment gMsgId in racy way in attempt to produce unique id for a request sent over AF_NETGRAPH socket. For long-lived multi-threaded application like net/mpd5 daemon: first thread can increase gMsgId upto INT_MAX and next moment another thread can increate gMsgId again to become -1. Then it is copied to unsigned msg.header.token a= nd returned as signed integer. This means false error status returned with errno=3D=3D0 and this breaks workflow of the daemon. I get this problem "in= wild" from time to time. I have very straightforward and naive patch protecting the variable with si= mple mutex (attached) but it has its penalty for performance. Usage of atomic operations should be better approach but I'm not familiar w= ith FreeBSD atomic operations. Any help will be appreciated. --=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-234442-7501>