[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1443821560.32531.60.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Fri, 02 Oct 2015 14:32:40 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Eric Dumazet <edumazet@...gle.com>,
Holger Hoffstätte
<holger.hoffstaette@...glemail.com>,
"David S. Miller" <davem@...emloft.net>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
netdev <netdev@...r.kernel.org>
Subject: Re: Soft lockup issue in Linux 4.1.9
On Fri, 2015-10-02 at 23:04 +0200, Thomas Gleixner wrote:
> On Fri, 2 Oct 2015, Eric Dumazet wrote:
> > On Fri, 2015-10-02 at 22:04 +0200, Thomas Gleixner wrote:
> >
> > > What makes sure, that the timer cannot be readded while that timer
> > > callback is running?
> >
> > What is exactly your question ?
>
> CPU0 CPU1
>
> timer expires
> callback
> add timer
> timer_pending() == true
> ===> del_timer_sync()
>
> I was just curious how this is prevented as I got lost in the
> networking code as usual :)
Sure ;)
I believe this can not happen for following reasons :
mod_timer_pinned() is used only when req is created, while timer cannot
possibly be running on the same req. The _pinned part is critical
because we set the req->refcnt _after_ starting the timer,
to avoid being visible and caught from rcu lookups in hash tables.
Then, timer might be modified only by mod_timer_pending() from
tcp_check_req() : This should not re-start timer if another cpu is in
the timer callback.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists