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.



Reply via email to