summaryrefslogtreecommitdiff
path: root/crypto
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2015-09-19 09:08:34 -0700
committerDavid S. Miller <davem@davemloft.net>2015-09-21 16:32:29 -0700
commited2e923945892a8372ab70d2f61d364b0b6d9054 (patch)
tree6df57f5b44b0003ac00ff559b781b691f91c4d13 /crypto
parent4c5d283acc997a1bd7bc37cddcf7d284521cffff (diff)
downloadlinux-ed2e923945892a8372ab70d2f61d364b0b6d9054.tar.gz
tcp/dccp: fix timewait races in timer handling
When creating a timewait socket, we need to arm the timer before allowing other cpus to find it. The signal allowing cpus to find the socket is setting tw_refcnt to non zero value. As we set tw_refcnt in __inet_twsk_hashdance(), we therefore need to call inet_twsk_schedule() first. This also means we need to remove tw_refcnt changes from inet_twsk_schedule() and let the caller handle it. Note that because we use mod_timer_pinned(), we have the guarantee the timer wont expire before we set tw_refcnt as we run in BH context. To make things more readable I introduced inet_twsk_reschedule() helper. When rearming the timer, we can use mod_timer_pending() to make sure we do not rearm a canceled timer. Note: This bug can possibly trigger if packets of a flow can hit multiple cpus. This does not normally happen, unless flow steering is broken somehow. This explains this bug was spotted ~5 months after its introduction. A similar fix is needed for SYN_RECV sockets in reqsk_queue_hash_req(), but will be provided in a separate patch for proper tracking. Fixes: 789f558cfb36 ("tcp/dccp: get rid of central timewait timer") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Ying Cai <ycai@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions