diff options
author | Eric Dumazet <edumazet@google.com> | 2015-09-19 09:08:34 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2015-09-21 16:32:29 -0700 |
commit | ed2e923945892a8372ab70d2f61d364b0b6d9054 (patch) | |
tree | 6df57f5b44b0003ac00ff559b781b691f91c4d13 /drivers/thermal/cpu_cooling.c | |
parent | 4c5d283acc997a1bd7bc37cddcf7d284521cffff (diff) |
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 'drivers/thermal/cpu_cooling.c')
0 files changed, 0 insertions, 0 deletions