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=234442 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=200557&action=edit 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 and returned as signed integer. This means false error status returned with errno==0 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 simple mutex (attached) but it has its penalty for performance. Usage of atomic operations should be better approach but I'm not familiar with FreeBSD atomic operations. Any help will be appreciated. -- 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>