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: <20110618193340.53811cbe@lxorguk.ukuu.org.uk>
Date:	Sat, 18 Jun 2011 19:33:40 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Nemo Publius <nemo@...f-evident.org>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Does Linux select() violate POSIX?

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

Actually no - there are lots of device cases where instantaneously it is
true that a read would not block but the condition then changes again.

An obvious simple example beyond that is a socket with two readers.

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

Linux follows Posix generally, but nobody writes portable code that does
blocking reads on a poll/select interface because there are a bazillion
ways it can then block - events read by other tasks, discards due to
memory exhaustion, events that are cleared the other end, etc.

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

It's a design decision and a huge performance win. It's one of the areas
where POSIX read in its strictest form cripples your performance.

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/