On Sat, 2017-02-04 at 17:59 +0800, Herbert Xu wrote: > Jason Baron <jba...@akamai.com> wrote: > > From: Jason Baron <jba...@akamai.com> > > > > sock_reset_flag() maps to __clear_bit() not the atomic version clear_bit(). > > Thus, we need smp_mb(), smp_mb__after_atomic() is not sufficient. > > > > Fixes: 3c7151275c0c ("tcp: add memory barriers to write space paths") > > Cc: Eric Dumazet <eric.duma...@gmail.com> > > Cc: Oleg Nesterov <o...@redhat.com> > > Signed-off-by: Jason Baron <jba...@akamai.com> > > This patch makes no sense. > > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > > index bfa165cc455a..1e22ae4a5b38 100644 > > --- a/net/ipv4/tcp_input.c > > +++ b/net/ipv4/tcp_input.c > > @@ -5028,7 +5028,7 @@ static void tcp_check_space(struct sock *sk) > > if (sock_flag(sk, SOCK_QUEUE_SHRUNK)) { > > sock_reset_flag(sk, SOCK_QUEUE_SHRUNK); > > /* pairs with tcp_poll() */ > > - smp_mb__after_atomic(); > > + smp_mb(); > > if (sk->sk_socket && > > test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) { > > tcp_new_space(sk); > > The comment says that it's pairing with an mb in tcp_poll, but > tcp_poll doesn't touch QUEUE_SHRUNK at all. So what exactly is > this barrier for?
Do not focus on QUEUE_SHRUNK flag, which is locally used by this thread only. The confusion comes because 3c7151275c0c9a80c3375f9874b1c7129a105eea thought it could avoid the cost of smp_mb() by abusing the fact that sock_reset_flag(sk, SOCK_QUEUE_SHRUNK) was doing an atomic, but it was not.