netdev - Re: [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: <563238D0.2040802@oracle.com>
Date:	Thu, 29 Oct 2015 15:18:40 +0000
From:	Alan Burlison <Alan.Burlison@...cle.com>
To:	David Holland <dholland-tech@...bsd.org>
CC:	Casper.Dik@...cle.com, Al Viro <viro@...IV.linux.org.uk>,
	David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
	stephen@...workplumber.org, netdev@...r.kernel.org
Subject: Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On 29/10/2015 14:58, David Holland wrote:

> ISTM that the best way to do this is to post a signal to the thread so
> accept bails with EINTR, at which point it can check to see if it's
> supposed to be exiting.

Yes, you could use pthread_kill, but that would require keeping a list 
of the tids of all the threads that were using the FD, and that really 
just moves the problem elsewhere rather than fixing it.

> Otherwise it sounds like the call you're looking for is not close(2)
> but revoke(2). Last I remember Linux doesn't have revoke because
> there's no way to implement it that isn't a trainwreck.

close(2) as per specified by POSIX works just fine on Solaris, if that 
was the case everywhere then it wouldn't be an issue. And for cases 
where it is necessary to keep the FD assigned because of races, the 
dup2(2) trick works fine as well.

-- 
Alan Burlison
--
--
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