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: <1445355027.22974.22.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Tue, 20 Oct 2015 08:30:27 -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 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 blocking system call using the same 'file'

This is the choice Linus Torvalds and Al Viro did years ago.

It is set in stone, unless someone comes up with a very nice patch set,
that does not break existing applications.

close() man page states :

NOTES
      It  is  probably unwise to close file descriptors while they may be in
      use by system calls in other threads in the  same  process.   Since  a
      file  descriptor may be reused, there are some obscure race conditions
      that may cause unintended side effects.

You are in this grey zone.


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