Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

>And no, I'm not fond of such irregular ways to pass file descriptors, but >we can't kill ioctl(2) with all weirdness hiding behind it, more's the pity... Yeah, there are a number of calls which supposed work on one but have a second argument which is also a file descriptor; mostly part of

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

>Yet another POSIX deficiency. > >When a server deals with 10,000,000+ socks, we absolutely do not care of >this requirement. > >O(log(n)) is still crazy if it involves O(log(n)) cache misses. You miss the fire point of the algorithm; you *always* find an available file descriptor in O(log(N))

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

>Ho-hum... It could even be made lockless in fast path; the problems I see >are > * descriptor-to-file lookup becomes unsafe in a lot of locking >conditions. Sure, most of that happens on the entry to some syscall, with >very light locking environment, but... auditing every sodding ioctl

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

>On Thu, Oct 22, 2015 at 08:34:19AM +0200, casper@oracle.com wrote: >> >> >> >And I'm really curious about the things Solaris would do with dup2() there. >> >Does it take into account the possibility of new accept() coming just as >> >dup2() is trying to terminate the ongoing ones? Is

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

From: Al Viro >Except that in this case "correctness" is the matter of rather obscure and >ill-documented areas in POSIX. Don't get me wrong - this semantics isn't >inherently bad, but it's nowhere near being an absolute requirement. It would more fruitful to have

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

>It's been said that the current mechanisms in Linux & some BSD variants >can be subject to races, and the behaviour exhibited doesn't conform to >POSIX, for example requiring the use of shutdown() on unconnected >sockets because close() doesn't kick off other threads accept()ing on >the same

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

>On Thu, Oct 22, 2015 at 08:24:51PM +0200, casper@oracle.com wrote: > >> The external behaviour atomic; you cannot distinguish the order >> between the closing of the original file (and waking up other threads >> waiting for a record lock) or changing the file referenced by that newfd. >> >>

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

From: Al Viro >On Thu, Oct 22, 2015 at 06:39:34PM +0100, Alan Burlison wrote: >> On 22/10/2015 18:05, Al Viro wrote: >> >> >Oh, for... Right in this thread an example of complete BS has been quoted >> >from POSIX close(2). The part about closing a file when the last

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

>And I'm really curious about the things Solaris would do with dup2() there. >Does it take into account the possibility of new accept() coming just as >dup2() is trying to terminate the ongoing ones? Is there a window when >descriptor-to-file lookups would fail? Looks like a race/deadlock

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

From: David Miller Date: Wed, 21 Oct 2015 08:30:08 -0700 (PDT) (17:30 CEST) >From: Alan Burlison >Date: Wed, 21 Oct 2015 15:38:51 +0100 > >> While this algorithm is pretty expensive, it is not often invoked. > >I bet it can be easily intentionally

Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

>On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote: > >> >There's going to be a notion of "last close"; that's what this refcount is >> >about and _that_ is more than implementation detail. >> >> Yes, POSIX distinguishes between "file descriptor" and "file >> description" (ugh!) and