[PATCH V2] Handle EAGAIN in wpa_supplicant_ctrl_iface_send

[Ben Greear]

On 09/25/2013 01:21 PM, Jouni Malinen wrote:
> On Wed, Sep 25, 2013 at 10:58:08AM -0700, Ben Greear wrote:
>> Have you tried just increasing the socket buffer sizes?  That would probably
>> be easier and more efficient than keeping a pending queue in supplicant.
>
> I haven't, but I don't think it would help either. The messages sent by
> wpa_supplicant for clients that never receive them seem to be stuck
> indefinitely and making the limit larger will just push out the
> inevitable issue a bit further. If there were a way to make kernel drop
> these eventually on some timeout that would obviously be helpful, but
> I'm not sure what that would be for unconnected AF_UNIX datagram socket.

I have never used PF_UNIX much...but this piece of code in the kernel
looks interesting:

/* When dgram socket disconnects (or changes its peer), we clear its receive
  * queue of packets arrived from previous peer. First, it allows to do
  * flow control based only on wmem_alloc; second, sk connected to peer
  * may receive messages only from that peer. */
static void unix_dgram_disconnected(struct sock *sk, struct sock *other)
{
	if (!skb_queue_empty(&sk->sk_receive_queue)) {
		skb_queue_purge(&sk->sk_receive_queue);
		wake_up_interruptible_all(&unix_sk(sk)->peer_wait);

		/* If one link of bidirectional dgram pipe is disconnected,
		 * we signal error. Messages are lost. Do not make this,
		 * when peer was not connected to us.
		 */
		if (!sock_flag(other, SOCK_DEAD) && unix_peer(other) == sk) {
			other->sk_err = ECONNRESET;
			other->sk_error_report(other);
		}
	}
}


It seems to me that it should go ahead and signal the other even if there
is nothing in the local rcv queue?  Sort of seems like someone would
have noticed this if it were a real problem though...

Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com