What version of Go are you using (go version)?

go1.20.5

$ go version

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Linux/amd64

What did you do?

We use net.FileConn to construct a net.Conn from a file descriptor passed in from another process via a unix socket.

net.FileConn calls internal/poll.FD.Init(net, true), which then makes the descriptor pollable conditional on poll configuration succeeding:

        err := fd.pd.init(fd)
        if err != nil {
                // If we could not initialize the runtime poller,
                // assume we are using blocking mode.
                fd.isBlocking = 1
        }

The trouble here is that fd.pd.init(fd) can produce an error when the number of poll watches exceeds /proc/sys/fs/epoll/max_user_watches, and thus the non-blocking file descriptor is incorrectly labelled as blocking.
The consequence of this is that calls to write(2), read(2), etc. that return EAGAIN do not invoke the netpoller and instead loop forever (or as long as the operation would block), which consumes 100% of the CPU time. Here's a flame graph I captured from a profile:

I think the correct fix here is to have poll.FD.Init produce a real error when netpoller registration fails.