JFYI. I've opened a follow-up differential for this potential regression: https://reviews.freebsd.org/D10351
Thanks! -Max On Mon, Apr 10, 2017 at 7:43 AM, Maxim Sobolev <sobo...@freebsd.org> wrote: > Hi Guys, I am sorry to bring this old thread up, but I think Ed's > comparison with other OSes here and in the relevant differential was not > entirely correct. What linux does (tested with 4.4.0) when UDP socket is > shut down is actually shutting down receiving end, so any threads that are > blocked in recv() on that socket return. Still shutdown() system call > itself returns ENOTCONN. FreeBSD on the other hand does not do anything for > the socket, so that the threads just hang. I am pretty sure there are at > least some software out there that relies on that behavior, at least in our > case we do. Bumped into this after upgrading to the 11.0. > > Therefore, I am curious about possibility to make our behavior match that > of Linux's, so we are not the odd one with regards to this, that is return > an error but still shutdown the socket? > > Small test case is attached. Both FreeBSD 10.3 and Linux 4.4.0 pass > (albeit Linux's shutdown() returns with an error), FreeBSD 11.0 fails. > > -Max > > On Sun, Aug 9, 2015 at 6:08 AM, Ed Schouten <e...@nuxi.nl> wrote: > >> Hi Alexander, >> >> 2015-08-09 14:55 GMT+02:00 Alexander Kabaev <kab...@gmail.com>: >> > On Sun, 9 Aug 2015 09:37:13 +0200 >> > It most definitely does work, this is what I have done to get my >> > network scripts work again. I wonder if there are other means of >> > restricting raw sockets that can be used to achieve the result >> > authors of rtsold had hoped or? >> >> Yes, there sure are. We could for example call cap_rights_limit() on >> the socket and whitelist the exacty set of actions that the program >> needs. >> >> That said, it wouldn't make a difference in the end. It looks like >> rtsol/rtsold don't seem to drop any privileges or switch credentials >> after startup, assuming I haven't overlooked anything. Even if we were >> to restrict the raw socket, the process could always open a new one >> later on. >> >> I think it would make sense for now to just commit the patch that I >> proposed. Will push it into the tree tomorrow. >> >> Thanks, >> -- >> Ed Schouten <e...@nuxi.nl> >> Nuxi, 's-Hertogenbosch, the Netherlands >> KvK/VAT number: 62051717 >> >> > _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
