netdev - RE: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR

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: <063D6719AE5E284EB5DD2968C1650D6D0F6EA4FF@AcuExch.aculab.com>
Date:	Thu, 27 Mar 2014 09:36:30 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Rainer Weikusat' <rweikusat@...ileactivedefense.com>,
	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: RE: [PATCH] net: unix: non blocking recvmsg() should not return
 -EINTR

From: Rainer Weikusat 
> Rainer Weikusat <rw@...le> writes:
> 
> [...]
> 
> > The underlying problem would seem to be that a O_NONBLOCK call might
> > actually block forever in case a blocking receiver sits on the lock and
> > no data is ever received.
> 
> ... except that this probably cannot happen because O_NONBLOCK is a file
> status flag and not a file descriptor flag.
> 
> NB: I've neither tested nor checked this.

While dup() gives a second fd referring to the same kernel 'file'
doing open("/dev/fd/4", ...) traditionally gives you an additional
'file' referring to the same vnode.
For real files the file offset is in the 'file' structure, and
I think the O_NONBLOCK flag is in the same place.
Which means that is possible (but maybe not that usual or sensible)
for a process to try a non-blocking read on a socket while another
process is blocked in the read code.

The same would be true for writes, and for writes to a datagram
socket it might even make sense.

In any case I expect EAGAIN to mean 'there is no data to read'
not 'something happened and I didn't bother to look for data'.

As the code stands (or with the suggested change) if a datagram
socket has an indefinite supply of data, and several processes
are doing nonblocking reads, and some are also receiving signals
then some of the reads will fail with EINTR/EAGAIN/EWOULDBLOCK.
That doesn't seem right.

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html