Date: Thu, 26 Jan 2017 20:15:57 -0800 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Mark Johnston <markj@FreeBSD.org> Cc: jch@FreeBSD.org, hiren@FreeBSD.org, Jason Eggleston <jeggleston@llnw.com>, rrs@FreeBSD.org, jtl@FreeBSD.org, net@FreeBSD.org Subject: Re: listening sockets as non sockets Message-ID: <20170127041557.GN2611@FreeBSD.org> In-Reply-To: <20170127014117.GA90480@raichu> References: <20170127005251.GM2611@FreeBSD.org> <20170127014117.GA90480@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 26, 2017 at 05:41:17PM -0800, Mark Johnston wrote: M> > It passes regression tests from tools/regression/sockets and tests/sys, M> > including the race tests, and including accept filter ones. M> M> I haven't yet looked much at the diff, so sorry in advance if this M> question is inappropriate. M> M> One problem I've fought a couple of times (with Infiniband SDP and unix M> sockets) is a race between accept(2) and a concurrent close of the M> listening socket. Right now, this problem has to be handled in the M> domain-specific code (see r303855 for instance), and it's generally M> awkward to do so. Does your work address this intrinsic race in any way? M> M> FWIW, I have a basic test case for unix sockets here, though I believe M> it's been incorporated into stress2: M> https://people.freebsd.org/~markj/unix_socket_detach.c This is strees2/misc/unix_socket_detach.sh, isn't it? My patch survived running it during night. I have also looked at r303855 and its code isn't touched by my patch. I will look further if the problem can be solved in general at socket layer. Thanks for point. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170127041557.GN2611>