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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 22 Oct 2015 08:34:19 +0200
To:	Al Viro <>
cc:	Alan Burlison <>,
	David Miller <>,,,,
Subject: Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3) 

>And I'm really curious about the things Solaris would do with dup2() there.
>Does it take into account the possibility of new accept() coming just as
>dup2() is trying to terminate the ongoing ones?  Is there a window when
>descriptor-to-file lookups would fail?  Looks like a race/deadlock country...

Solaris does not "terminate" threads, instead it tells them that the
file descriptor information used is stale and wkae's up the thread.

The accept call gets woken up and it checks for incoming connections; it 
will then either find a new connection and returns that particular 
connection or it will find nothing and returns EINTR; in the post-syscall 
glue this is checked (the kernel thread has been told to take the 
expensive post-syscall routine) and if the system call was interrupted, 
EBADF is returned instead.

It is also possible for the connection to come in late and then the socket 
will be changed and the already accepted (in TCP terms, not in the
socket API terms) embryonic will be closed too as is normal when a 
listening socket is closed with a list of not ready accept()ed connections.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists