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

From: casper@oracle.com > Sent: 21 October 2015 21:33 .. > >Er... So fd2 = dup(fd);accept(fd)/close(fd) should *not* trigger that > >behaviour, in your opinion? Because fd is sure as hell not the last > >descriptor refering to that socket - fd2 remains alive and well. > > > >Behaviour you

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

On Mon, Nov 02, 2015 at 10:03:58AM +, David Laight wrote: > Remember, Solaris (and SYSV) has extra levels of multiplexing between > userspace and char special drivers (and probably sockets) than Linux does. > As well as having multiple fd referencing the same struct FILE, multiple > FILE can

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: > On 21/10/2015 04:49, Al Viro wrote: > >BTW, for real fun, consider this: > >7) > >// fd is a socket > >fd2 = dup(fd); > >in thread A: accept(fd); > >in thread B: accept(fd); > >in thread C: accept(fd2); > >in thread D:

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

On Fri, Oct 23, 2015 at 06:30:25PM +, David Holland wrote: > So, I'm coming late to this discussion and I don't have the original > context; however, to me this cited behavior seems undesirable and if I > ran across it in the wild I would probably describe it as a bug. Unfortunately, that's

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

On Thu, Oct 22, 2015 at 11:55:42AM +0100, Alan Burlison wrote: > On 22/10/2015 05:21, Al Viro wrote: > > >>Most of the work on using a file descriptor is local to the thread. > > > >Using - sure, but what of cacheline dirtied every time you resolve a > >descriptor to file reference? > > Don't

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

On 22/10/2015 05:21, Al Viro wrote: Most of the work on using a file descriptor is local to the thread. Using - sure, but what of cacheline dirtied every time you resolve a descriptor to file reference? Don't you have to do that anyway, to do anything useful with the file? How much does

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

On 22/10/15 19:16, Al Viro wrote: Don't you have to do that anyway, to do anything useful with the file? Dirtying the cacheline that contains struct file itself is different, but that's not per-descriptor. Yes, true enough. Usually it's per-process, but any thread could ask for a private

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

On Wed, 2015-10-21 at 14:03 +0100, Alan Burlison wrote: > On 21/10/2015 12:28, Eric Dumazet wrote: > > > This works for me. Please double check your programs > > I have just done so, it works as you say for AF_INET sockets but if you > switch to AF_UNIX sockets it does the wrong thing in the

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

On 21/10/2015 04:49, Al Viro wrote: Firstly, thank you for the comprehensive and considered reply. Refcount is an implementation detail, of course. However, in any Unix I know of, there are two separate notions - descriptor losing connection to opened file (be it from close(), exit(),

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

On Wed, Oct 21, 2015 at 10:33:04PM +0200, casper@oracle.com wrote: > > >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. > >> > >>

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

On Wed, 2015-10-21 at 15:38 +0100, Alan Burlison wrote: > -- > Since at least Solaris 7 (1998), a thread which is sleeping > on a file descriptor which is being closed by another thread, > will be woken up. > > To this end each thread keeps a list of file descriptors > in use by the

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 the

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

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

On 21/10/2015 19:51, Al Viro wrote: BTW, is SCM_RIGHTS outside of scope? They do mention it in one place only: | Ancillary data is also possible at the socket level. The | header shall define the following symbolic constant for use as the cmsg_type | value when cmsg_level is SOL_SOCKET: | |

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

On 21/10/2015 12:28, Eric Dumazet wrote: This works for me. Please double check your programs I have just done so, it works as you say for AF_INET sockets but if you switch to AF_UNIX sockets it does the wrong thing in the way I described. -- Alan Burlison -- -- To unsubscribe from this

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

From: Alan Burlison > Sent: 20 October 2015 19:31 ... > The problem with poll() is that it returns immediately when passed a FD > that is in the listening state. rather than waiting until there's an > incoming connection to handle. As I said, that means you can't use > poll() to multiplex between

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

On 21/10/2015 11:25, David Laight wrote: The problem with poll() is that it returns immediately when passed a FD that is in the listening state. rather than waiting until there's an incoming connection to handle. As I said, that means you can't use poll() to multiplex between read/write/accept

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

On Wed, 2015-10-21 at 11:49 +0100, Alan Burlison wrote: > On 21/10/2015 11:25, David Laight wrote: > > >> The problem with poll() is that it returns immediately when passed a FD > >> that is in the listening state. rather than waiting until there's an > >> incoming connection to handle. As I

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

On 20/10/2015 02:45, Eric Dumazet wrote: On Tue, 2015-10-20 at 02:12 +0100, Alan Burlison wrote: Another problem is that if I call close() on a Linux socket that's in accept() the accept call just sits there until there's an incoming connection, which succeeds even though the socket is

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

On 20/10/2015 16:30, Eric Dumazet wrote: A close() does _not_ wakeup an accept() or a poll() (this is exactly the same problem), or any blocking system call using the same 'file' Not waking up the accept() is one thing, allowing the accept() to successfully complete some indeterminate time

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

On Tue, 2015-10-20 at 19:31 +0100, Alan Burlison wrote: > No, the race issue with file descriptor reuse and the close() behaviour > are not the same thing. The manpage comment is correct, but not relevant. Ok, it seems you know better than me, I will be stop the discussion and wait for your

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

On Tue, 2015-10-20 at 14:45 +0100, Alan Burlison wrote: > And I still haven't seen any reasoning behind the Linux close() and > poll() behaviour on sockets that are in the listen state. Same answer. A close() does _not_ wakeup an accept() or a poll() (this is exactly the same problem), or any

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

On Mon, Oct 19, 2015 at 06:45:32PM -0700, Eric Dumazet wrote: > On Tue, 2015-10-20 at 02:12 +0100, Alan Burlison wrote: > > > Another problem is that if I call close() on a Linux socket that's in > > accept() the accept call just sits there until there's an incoming > > connection, which

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

On Tue, 2015-10-20 at 10:59 +0100, Alan Burlison wrote: > That may be how Linux implements accept(), but I don't see anything > about refcounting in the POSIX spec for accept(). That's an internal implementation detail. POSIX does not document linux kernel overall design and specific tricks.

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

On 20/10/2015 14:19, Eric Dumazet wrote: That may be how Linux implements accept(), but I don't see anything about refcounting in the POSIX spec for accept(). That's an internal implementation detail. POSIX does not document linux kernel overall design and specific tricks. No, neither does

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

On Mon, 2015-10-19 at 09:59 -0700, Stephen Hemminger wrote: > This looks like corner case, but worth forwarding. > > Begin forwarded message: > > Date: Mon, 19 Oct 2015 13:21:33 + > From: "bugzilla-dae...@bugzilla.kernel.org" > > To:

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

On 20/10/2015 00:33, Eric Dumazet wrote: It looks it is a long standing problem, right ? Yep, seems so. inet_shutdown() has this very specific comment from beginning of git tree : switch (sk->sk_state) { ... /* Remaining two branches are temporary solution for missing

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

On Tue, 2015-10-20 at 02:12 +0100, Alan Burlison wrote: > Another problem is that if I call close() on a Linux socket that's in > accept() the accept call just sits there until there's an incoming > connection, which succeeds even though the socket is supposed to be > closed, but then an