Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> Sort of. The wakeup may occur for several reasons and you need to check
> the return (for signals). Also the wakeup can occur when there is room
> but another thread fills it, or return room but not enough for a large
> datagram. Those don't seem to be the case on your example
I've traced the problem to datagram_poll(). This function doesn't
check if the receiver queue has at least one slot empty, it only
checks sock_writeable() i.e. if:
atomic_read(&sk->wmem_alloc) < (sk->sndbuf / 2);
unix_dgram_sendmsg() can then block on:
if (unix_peer(other) != sk &&
skb_queue_len(&other->receive_queue) > other->max_ack_backlog) {
if (!timeo) {
err = -EAGAIN;
goto out_unlock;
Now the question is how should the problem be fixed?
I've tried using modified datagram_poll():
+ unix_socket *other = NULL;
- if (sock_writeable(sk))
+ other = unix_peer_get(sk);
+ if (sock_writeable(sk) && other &&
+ skb_queue_len(&other->receive_queue) <= other->max_ack_backlog)
mask |= POLLOUT | POLLWRNORM | POLLWRBAND;
else
set_bit(SOCK_ASYNC_NOSPACE, &sk->socket->flags);
but unix_peer_get(sk) returns NULL.
How can I examine the receiver queue length?
Should I worry about "restarts" as in unix_dgram_sendmsg()?
Maybe someone has a fix ready?
I've attached the userspace tests, a modified version of someone's real
program - recv should be run first, send should be straced.
The problem is present in both 2.5.70 and 2.4.20rc7.
-- Krzysztof Halasa Network Administrator
This archive was generated by hypermail 2b29 : Sat Jun 07 2003 - 22:00:25 EST