[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpVpjhSLGrqQAL4N=X3hqcZBQd1F+2QzO+7rmLJijq4hRA@mail.gmail.com>
Date: Wed, 8 Feb 2017 13:50:57 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Kaiwen Xu <kevin@...xu.net>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: loopback device reference count leakage
On Mon, Feb 6, 2017 at 6:32 PM, Kaiwen Xu <kevin@...xu.net> wrote:
> Hi Cong,
>
> I did some more testing, seems like your second assumption is correct.
> There is indeed some things holding the references to a particular dst
> which preventing it to be gc'ed.
Excellent!
>
> I added logging to each dst_hold (or dst_hold_safe, or
> skb_dst_force_safe) and dst_release, which formatted as following:
>
> <dev name> (<protocol>) [<dst addr>]: dst_release / dst_hold ... <refcnt> <caller function>
>
> And inside dst_gc_task(), I added logging when gc delay occurred,
> formatted as:
>
> [dst_gc_task] <dev name> (<protocol>): delayed <refcnt>
>
> I have the log attached.
The following line looks suspicious:
Feb 6 16:27:24 <hostname> kernel: [63589.458067] [dst_gc_task]
lodebug (2): delayed 19
Looks like you ended up having one dst whose refcnt is 19 in GC,
and this lasted for a rather long time for some reason.
It is hard to know if it is a refcnt leak even with your log, since there were
4K+ refcnt'ing happened on that dst...
Meanwhile, can you share your setup of your container? What network device
do you use in your container? How is it connected to outside?
Thanks.
Powered by blists - more mailing lists