[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1512161486.19682.45.camel@gmail.com>
Date: Fri, 01 Dec 2017 12:51:26 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, maze@...gle.com
Subject: Re: [PATCH net] tcp/dccp: block bh before arming time_wait timer
On Fri, 2017-12-01 at 15:12 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Fri, 01 Dec 2017 10:06:56 -0800
>
> > From: Eric Dumazet <edumazet@...gle.com>
> >
> > Maciej Żenczykowski reported some panics in tcp_twsk_destructor()
> > that might be caused by the following bug.
> >
> > timewait timer is pinned to the cpu, because we want to transition
> > timwewait refcount from 0 to 4 in one go, once everything has been
> > initialized.
> >
> > At the time commit ed2e92394589 ("tcp/dccp: fix timewait races in
> timer
> > handling") was merged, TCP was always running from BH habdler.
> >
> > After commit 5413d1babe8f ("net: do not block BH while processing
> > socket backlog") we definitely can run tcp_time_wait() from process
> > context.
> >
> > We need to block BH in the critical section so that the pinned
> timer
> > has still its purpose.
> >
> > This bug is more likely to happen under stress and when very small
> RTO
> > are used in datacenter flows.
> >
> > Fixes: 5413d1babe8f ("net: do not block BH while processing socket
> backlog")
> > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > Reported-by: Maciej Żenczykowski <maze@...gle.com>
>
> Applied and queued up for -stable, thanks Eric.
It just occurred to me that we can now revert 614bdd4d6e61d26
("tcp: must block bh in __inet_twsk_hashdance()")
Powered by blists - more mailing lists