linux-kernel - Re: bug in select() in linux

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-next>] [day] [month] [year] [list]

Message-ID: <45219fb00703120802y78cf4dbds6e89b58de9d0f801@mail.gmail.com>
Date:	Mon, 12 Mar 2007 16:02:11 +0100
From:	"Lluís Batlle" <viriketo@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: bug in select() in linux

Oh, of course you're right. I was inside too much layers to think of
the tcp protocol, and I did not pay attention to it.

Maybe something could be added to the manpage anyway.

The bad thing is that there's no way I can use a socket for writing
using select() if that connection has been half-closed by the other
end. Moo.

Thanks a lot for your time,
Lluís

2007/3/12, Alan Cox <alan@...rguk.ukuu.org.uk>:
> > I've tried a select() for write against a closed tcp socket (closed by
> > the other side), and the select call _blocks_.
>
> A TCP close from the remote node is single sided. It sends a FIN and we
> ACK the FIN, that means only that the remote node has completed *sending*.
>
> > Any write() call to that socket will _not block_, and will return with EPIPE.
>
> We don't know this until you try the write. At that point the other end
> if it has closed entirely will issue an RST and terminate the connection
> in full.
>
> I don't therefore believe that this is actually a bug.
>
> Alan
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/