On 23/10/2015 17:19, Eric Dumazet wrote:

quoted

quoted

The AF_UNIX poll one? No, I don't have the means to do so, and in any
case that's not a POSIX issue, just a plain bug. I'm happy to log a bug
if that helps.

BTW, there is no kernel bug here. POSIX poll() man page says :

POLLOUT
     Normal data may be written without blocking.

If you attempt to write on a listener, write() does _not_ block and
returns -1, which seems correct behavior to me, in accordance with man
page.

Except of course data may not be written, because an attempt to actually 
do so fails, because the socket is in the listen state, is not connected 
and therefore no attempt to write to it could ever succeed. The only bit 
of the required behaviour that the current AF_UNIX poll implementation 
actually gets right is the "without blocking" bit, and that's only the 
case because the failure is detected immediately and the write call 
returns immediately with an error.

socket(PF_LOCAL, SOCK_STREAM, 0)        = 3
bind(3, {sa_family=AF_LOCAL, sun_path=@""}, 110) = 0
listen(3, 10)                           = 0
write(3, "test", 4)                     = -1 ENOTCONN (Transport endpoint is not connected)

Could you point out which part of POSIX is mandating that af_unix
listener MUST filter out POLLOUT ?

"A file descriptor for a socket that is listening for connections shall 
indicate that it is ready for reading, once connections are available. A 
file descriptor for a socket that is connecting asynchronously shall 
indicate that it is ready for writing, once a connection has been 
established."

If POSIX had to explicitly list every possible thing that 
implementations *should not* do rather than just those that they 
*should* do then it would be even more unwieldy than it already is.

And if what you are asserting is correct, why isn't the AF_INET 
behaviour the same as the AF_UNIX behaviour?

-- 
Alan Burlison
--