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: <1445947270.7476.7.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Tue, 27 Oct 2015 05:01:10 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alan Burlison <Alan.Burlison@...cle.com>
Cc:	Casper.Dik@...cle.com, Al Viro <viro@...IV.linux.org.uk>,
	David Miller <davem@...emloft.net>, stephen@...workplumber.org,
	netdev@...r.kernel.org, dholland-tech@...bsd.org
Subject: Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On Tue, 2015-10-27 at 10:52 +0000, Alan Burlison wrote:

> Unfortunately Hadoop isn't the only thing that pulls the shutdown() 
> trick, so I don't think there's a simple fix for this, as discussed 
> earlier in the thread. Having said that, if close() on Linux also did an 
> implicit shutdown() it would mean that well-written applications that 
> handled the scoping, sharing and reuse of FDs properly could just call 
> close() and have it work the same way across *NIX platforms.


Are non multi threaded applications considered well written ?

listener = socket(...);
bind(listener, ...);
listen(fd, 10000);
Loop 1 10
  if (fork() == 0)
    do_accept(listener)

Now if a child does a close(listener), or is killed, you propose that it
does an implicit shutdown() and all other children no longer can
accept() ?

Surely you did not gave all details on how it is really working.





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