netdev - Re: [PATCH net] tcp: correct memory barrier usage in tcp_check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170204095954.GA5916@gondor.apana.org.au>
Date:   Sat, 4 Feb 2017 17:59:54 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Jason Baron <jbaron@...mai.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        eric.dumazet@...il.com, oleg@...hat.com
Subject: Re: [PATCH net] tcp: correct memory barrier usage in
 tcp_check_space()

Jason Baron <jbaron@...mai.com> wrote:
> From: Jason Baron <jbaron@...mai.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.dumazet@...il.com>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Signed-off-by: Jason Baron <jbaron@...mai.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?

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt