linux-kernel - Re: Does Linux select() violate POSIX?

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: <BANLkTi=Vis=aZ5vn7E0A2LGVPOcmjd+r-g@mail.gmail.com>
Date:	Sat, 18 Jun 2011 11:22:57 -0700
From:	Nemo Publius <nemo@...f-evident.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Does Linux select() violate POSIX?

First, thank you for your reply.

On Sat, Jun 18, 2011 at 10:43 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le samedi 18 juin 2011 à 10:06 -0700, Nemo Publius a écrit :
>> Suppose I  have a file descriptor referencing a TCP/IP socket in blocking mode.
>>
>> Suppose select() reports that the descriptor is ready for reading.
>>
>> If I then call recv() on that descriptor, can it _ever_ block?
>>
>>
>> According to the Linux select man page
>> (http://linux.die.net/man/2/select), the answer is yes:
>> ...
>
> Only UDP can currently do that, not TCP, if NIC did not already verified
> the checksum.
>
> So the answer to your question is no.

You mean the answer happens to be "no" for reading a TCP socket with
the current Linux implementation, but that is not considered part of
the interface, so the behavior could change in the future and so I
cannot depend on it?

>> According to the POSIX specification for select
>> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html),
>> the answer is no:
>> ...
>
>
> We dont care, since every sane application using select() should also
> use socket in non blocking mode.

This is simply not true for any POSIX-compliant operating system.
Which in this case happens to include every Unix ever written since
the beginning of time, apart from Linux.

Put another way...  The whole point of the POSIX spec is to allow me
to write portable code.  If every random Unix implementation makes up
its own mind about what is "sane" and violates the spec in arbitrary
and unpredictable ways, what is the point of having a spec?

> Between time select()/poll() says 'OK you can go', and time you enter
> kernel, conditions might have changed. For example, maybe kernel memory
> is not available and a send() would _block_, even if socket queue is
> empty.

Sounds like a kernel bug.
--
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/