Date: Sat, 14 Apr 2018 19:42:45 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 227285] File descriptor passing does not work reliably on SMP system Message-ID: <bug-227285-227-IoNRA3GtJ1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-227285-227@https.bugs.freebsd.org/bugzilla/> References: <bug-227285-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227285 Jan Kokemüller <jan.kokemueller@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #192514|text/x-csrc |text/plain mime type| | --- Comment #6 from Jan Kokemüller <jan.kokemueller@gmail.com> --- Created attachment 192514 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192514&action=edit test program (faster reproduction) Here is a better test program that should uncover the race in a few seconds at most. Compile with "cc fdpass-race-fast.c -pthread -lnv". I'm spawning another thread that just creates and closes socketpairs. This triggers the unp garbage collector constantly. I believe the race is in soreceive_generic() in sys/kern/uipc_socket.c. The "in flight" domain socket is taken off the so_rcv sockbuf, but it is not externalized yet (dom_externalize() hasn't been called). This leads to the GC thinking that the socket is still "in flight" but it doesn't actually get marked because it is off the so_rcv sockbuf. Now the GC thinks this socket is unreachable and closes it. -- 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-227285-227-IoNRA3GtJ1>