Date: Wed, 04 Apr 2018 14:34:51 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 227285] File descriptor passing does not work reliably on SMP system (cache coherency issue?) Message-ID: <bug-227285-8-uOQD6WJwIk@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-227285-8@https.bugs.freebsd.org/bugzilla/> References: <bug-227285-8@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=3D227285 --- Comment #2 from Jan Kokem=C3=BCller <jan.kokemueller@gmail.com> --- Created attachment 192214 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D192214&action= =3Dedit excerpt of Dtrace script output Here is part of the Dtrace debug log. When 'got err' is printed it means that the parent could not read the byte = from the child. At this point the address of the receive sockbuf is 'fffff801071df148' and the SBS_CANTRCVMORE flag is set (CPU 1). However, further above, this sockbuf looks fine in the child (CPU 3) and th= ere aren't any calls to socantrcvmore_locked() in the meantime. Even further above, this sockbuf was destroyed by the parent in a previous iteration (CPU 1) and therefore SBS_CANTRCVMORE is set. But this should not affect the current iteration. It looks like the memory from the child proce= ss on CPU 3 isn't made visible to CPU 1 properly. --=20 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-8-uOQD6WJwIk>