Re: [PATCH V2] net: add accounting for socket backlog

[Eric Dumazet <eric.dumazet@gmail.com>]

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;
 }
 
 /**