[Bug 234442] libnetgraph race condition

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: eugen at freebsd.org
                CC: avg at FreeBSD.org, glebius at FreeBSD.org, kib at FreeBSD.org,
                    mav at 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.