ThreadSanitizer detected data race in EpollEventLoop

Expected behavior

ThreadSantizer doesn’t find any race conditions

Actual behavior

ThreadSanitizer found data race as follows:

Code in io.netty.channel.epoll.EpollEventLoop.java:521

            try {
                eventFd.close();
            } catch (IOException e) {
                logger.warn("Failed to close the event fd.", e);
            }

Code in io.netty.channel.epoll.EpollEventLoop.java:183

    protected void wakeup(boolean inEventLoop) {
        if (!inEventLoop && nextWakeupNanos.getAndSet(AWAKE) != AWAKE) {
            // write to the evfd which will then wake-up epoll_wait(...)
            Native.eventFdWrite(eventFd.intValue(), 1L);
        }
    }

Access to eventFd (which is a FileDescriptor) should be protected with a lock.

Steps to reproduce

Run a bigtable test with TSAN enabled for 100 runs.

Minimal yet complete reproducer code (or URL to code)

Netty version

4.1.52.Final

JVM version (e.g. java -version)

JDK11

OS version (e.g. uname -a)

Not known

[ejona86]

I tracked this down and confirmed a false positive in TSAN. A test suddenly started triggering TSAN more frequently which made it easier to toy with and I confirmed that TSAN didn’t detect epoll waking as a form of synchronization. I was able to create a minimal C reproduction which was handled quickly by some TSAN folks to produce https://reviews.llvm.org/D124518 .

[normanmaurer]

@sanjaypujare actually I think this is a false postive and harmless. Using the eventFD in a multi-threaded environment is actually valid and expected. @ejona86 WDYT ?