[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1267443828.3039.7.camel@edumazet-laptop>
Date: Mon, 01 Mar 2010 12:43:48 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Zhu Yi <yi.zhu@...el.com>
Cc: netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [PATCH V2] net: add accounting for socket backlog
Le dimanche 28 février 2010 à 06:31 +0100, Eric Dumazet a écrit :
> I am afraid sk_backlog_rcv() is not always called with lock held, and
> not always called to process backlog (see TCP ucopy.prequeue)
>
> If you take a look at __release_sock() for example, we make the backlog
> private to the process before handling it (outside of lock_sock())
>
> Therefore, I suggest doing the 'substraction' outside of
> sk_backlog_rcv().
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index e1f6f22..57271cb 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1520,6 +1520,7 @@ static void __release_sock(struct sock *sk)
>
> do {
> sk->sk_backlog.head = sk->sk_backlog.tail = NULL;
> + sk->sk_backlog.len = 0;
> bh_unlock_sock(sk);
>
> do {
>
>
Thinking again about this, doing this zero initialization at the very
end of __release_sock() solves the problem of potential infinite loop in
__release_sock(). Since producer will hit the backlog limit.
Thanks
diff --git a/net/core/sock.c b/net/core/sock.c
index 305cba4..544cf4a 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1542,6 +1542,11 @@ static void __release_sock(struct sock *sk)
bh_lock_sock(sk);
} while ((skb = sk->sk_backlog.head) != NULL);
+ /*
+ * Doing this zeroing at the end of this function guarantee we can not
+ * loop forever while a wild producer attempts to flood us
+ */
+ sk->sk_backlog.len = 0;
}
/**
--
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
Powered by blists - more mailing lists