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: n...@freebsd.org
Reporter: eu...@freebsd.org
CC: a...@freebsd.org, gleb...@freebsd.org, k...@freebsd.org,
m...@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.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
