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: Windows password security audit tool. GUI, reports in PDF.

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

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

On Sat, Feb 04, 2017 at 07:19:37AM -0800, Eric Dumazet wrote:
>
> > 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.

Thanks for the explanation.  I see what it's protecting now.  And
this could indeed be responsible for the race that Oleg reported.
-- 
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