[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1321939381.27077.7.camel@edumazet-laptop>
Date: Tue, 22 Nov 2011 06:23:01 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Alexey Moiseytsev <himeraster@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] AF_UNIX: Fix poll locking problem when reading from
a stream socket
Le mardi 22 novembre 2011 à 03:35 +0400, Alexey Moiseytsev a écrit :
> poll() call may be locked by concurrent reading from the same stream
> socket.
>
> Signed-off-by: Alexey Moiseytsev <himeraster@...il.com>
> ---
> net/unix/af_unix.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 466fbcc..b595a3d 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1957,6 +1957,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
> if ((UNIXCB(skb).pid != siocb->scm->pid) ||
> (UNIXCB(skb).cred != siocb->scm->cred)) {
> skb_queue_head(&sk->sk_receive_queue, skb);
> + sk->sk_data_ready(sk, skb->len);
> break;
> }
> } else {
> @@ -1974,6 +1975,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
> chunk = min_t(unsigned int, skb->len, size);
> if (memcpy_toiovec(msg->msg_iov, skb->data, chunk)) {
> skb_queue_head(&sk->sk_receive_queue, skb);
> + sk->sk_data_ready(sk, skb->len);
> if (copied == 0)
> copied = -EFAULT;
> break;
> @@ -1991,6 +1993,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
> /* put the skb back if we didn't use it up.. */
> if (skb->len) {
> skb_queue_head(&sk->sk_receive_queue, skb);
> + sk->sk_data_ready(sk, skb->len);
> break;
> }
>
> @@ -2006,6 +2009,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
>
> /* put message back and return */
> skb_queue_head(&sk->sk_receive_queue, skb);
> + sk->sk_data_ready(sk, skb->len);
> break;
> }
> } while (size);
Fine, the fix is technically correct since we own u->readlock mutex,
another thread cannot consume the just requeued skb.
Small note : the words "locking" and "locked" are more used to describe
the action of taking a spinlock/mutex/rwlock or something, while the bug
you fixed is more about poll() system call being blocked/frozen forever.
Thanks !
Acked-by: Eric Dumazet <eric.dumazet@...il.com>
--
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/
Powered by blists - more mailing lists