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: <56324625.9000803@oracle.com>
Date:	Thu, 29 Oct 2015 16:15:33 +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 16:01, David Holland wrote:

> Hardly; it moves the burden of doing stupid things to the
> application. If as you said the goal is to shut down all threads
> cleanly, then it doesn't need to keep track in detail anyway; it can
> just post SIGTERM to every thread, or SIGUSR1 if SIGTERM is bad for
> some reason, or whatever.

I agree that the root issue is poor application design, but posting a 
signal to every thread is not a solution if you only want to shut down a 
subset of threads.

> close(2) as specified by POSIX doesn't prohibit this weird revoke-like
> behavior, but there's nothing in there that mandates it either. (I
> thought this discussion had already clarified that.)

There was an attempt to interpret POSIX that way, with which I still 
disagree. If a FD is closed or reassigned then any current pending 
operations on it should be terminated.

> Note that while NetBSD apparently supports this behavior because
> someone copied it from Solaris, I'm about to go recommend it be
> removed.

Which behaviour? The abort accept() on close() behaviour?

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