[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150311.175345.836846566788322568.davem@davemloft.net>
Date: Wed, 11 Mar 2015 17:53:45 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: eric.dumazet@...il.com
Cc: netdev@...r.kernel.org, salo@...gle.com
Subject: Re: [PATCH net-next] net: add real socket cookies
From: Eric Dumazet <eric.dumazet@...il.com>
Date: Tue, 10 Mar 2015 15:45:33 -0700
> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index 14d02ea905b6..a097ae38b639 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -678,7 +678,8 @@ struct sock *inet_csk_clone_lock(const struct sock *sk,
> newsk->sk_write_space = sk_stream_write_space;
>
> newsk->sk_mark = inet_rsk(req)->ir_mark;
> -
> + atomic64_cmpxchg(&newsk->sk_cookie, 0,
> + atomic64_read(&inet_rsk(req)->ir_cookie));
> newicsk->icsk_retransmits = 0;
> newicsk->icsk_backoff = 0;
> newicsk->icsk_probes_out = 0;
I think you have to be more careful here.
sk_clone_lock() is not going to zero out sk_cookie for you, it only
does so if the priority has __GFP_ZERO in it and some callsites use
just plain GFP_ATOMIC.
Therefore, you can't just assume sk_cookie is zero.
Just use atomic64_set() here, you have exclusive access to this piece
of memory at this point in time, and you'll save an unnecessary atomic
operation as well.
--
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