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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1445305532.30896.40.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Mon, 19 Oct 2015 18:45:32 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alan Burlison <Alan.Burlison@...cle.com>
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	netdev@...r.kernel.org
Subject: 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 immediately following accept() on the same socket 
> fails. 

This is exactly what the comment I pasted documents.

On linux, doing close(listener) on one thread does _not_ wakeup other
threads doing accept(listener)

So I guess allowing shutdown(listener) was a way to somehow propagate
some info on the threads stuck in accept()

This is a VFS issue, and a long standing one.

Think of all cases like dup() and fd passing games, and the close(fd)
being able to signal out of band info is racy.

close() is literally removing one ref count on a file.
Expecting it doing some kind of magical cleanup of a socket is not
reasonable/practical.

On a multi threaded program, each thread doing an accept() increased the
refcount on the file.

Really, I have no idea of how Solaris coped with this, and I do not want
to know.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html