From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: David Miller <davem@davemloft.net>
Cc: akpm@linux-foundation.org, xemul@openvz.org,
bugme-daemon@bugzilla.kernel.org, nigel@suspend2.net,
netdev@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 9778] New: unregister_netdevice: waiting for [device] to become free
Date: Mon, 21 Jan 2008 15:14:45 +0300 [thread overview]
Message-ID: <20080121121445.GA29459@2ka.mipt.ru> (raw)
In-Reply-To: <20080120.023027.85710827.davem@davemloft.net>
On Sun, Jan 20, 2008 at 02:30:27AM -0800, David Miller (davem@davemloft.net) wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Sat, 19 Jan 2008 16:58:02 -0800
>
> > ouch.
>
> Yep, several people are hitting this it seems.
>
> If Pavel doesn't provide a fix or direction soon I'll just revert.
It looks like patch is still valid.
Here is a problem description as I undestood.
When new device (let's talk about ethernet, since that is what I tested)
is being turned on, it gets neigh_parms entry allocated for it via
inetdev_init(), which is called for NETDEV_REGISTER inetdev event.
This entry is stored in arp_tbl table and is in_dev->arp_parms.
When later new arp entry is created, device is provided into
arp_constructor(), which clones (increase reference counter) device's
in_dev->arp_parms and puts it into provided neighbour entry.
When later we remove device, its in_dev->arp_parms's reference counter
is high enough (it is equal to number of arp entries found on given
device plu one), so neigh_parms_destroy() is not called. Later all
neighbour entries are flushed by garbage collector and reference counter
for that parm hits zero and device can be removed.
I will think about how to fix the problem nicely or if this patch still
can be simplified/dropped, but so far it looks valid. Maybe this
analysis will help someone to fix problem first.
Here is debug dmesg:
[ 21.835595] inetdev_init: allocating parms.
[ 21.839829] neigh_parms_alloc: parms: ffff81003d8e8df0, dev: eth0, refcnt: 1, dev_refcnt: 2.
...
[ 30.251576] r8169: eth0: link up
[ 31.067079] NET: Registered protocol family 10
[ 31.072055] neigh_parms_alloc: parms: ffff81003efc72a8, dev: lo, refcnt: 1, dev_refcnt: 9.
[ 31.080891] neigh_alloc: parms: ffffffff8812afe8, dev: <NULL>, refcnt: 2.
[ 31.087816] neigh_parms_alloc: parms: ffff81003efc7210, dev: eth0, refcnt: 1, dev_refcnt: 9.
[ 31.097335] neigh_alloc: parms: ffffffff804deb88, dev: <NULL>, refcnt: 2.
[ 31.104172] arp_constructor: parms: ffff81003f8c3be8, dev: lo, refcnt: 2.
[ 31.500348] neigh_alloc: parms: ffffffff8812afe8, dev: <NULL>, refcnt: 2.
[ 32.499628] neigh_alloc: parms: ffffffff8812afe8, dev: <NULL>, refcnt: 2.
[ 102.827796] neigh_destroy: parms: ffff81003efc7210, dev: eth0, refcnt: 3, dev_refcnt: 13.
[ 106.828843] neigh_destroy: parms: ffff81003f8c3be8, dev: lo, refcnt: 2, dev_refcnt: 78.
[ 109.810987] neigh_alloc: parms: ffffffff804deb88, dev: <NULL>, refcnt: 2.
First arp entry for eth0 device, bump the counter:
[ 109.817827] arp_constructor: parms: ffff81003d8e8df0, dev: eth0, refcnt: 2.
[ 109.831811] neigh_alloc: parms: ffffffff804deb88, dev: <NULL>, refcnt: 2.
[ 109.838661] arp_constructor: parms: ffff81003f8c3be8, dev: lo, refcnt: 2.
[ 110.837894] neigh_destroy: parms: ffff81003efc7210, dev: eth0, refcnt: 2, dev_refcnt: 15.
Can not release that neigh parm:
[ 113.638228] neigh_parms_release: parms: ffff81003d8e8df0, dev: eth0, refcnt: 2, dev_refcnt: 5.
Can release some other (for ipv6):
[ 113.649380] neigh_parms_release: parms: ffff81003efc7210, dev: eth0, refcnt: 1, dev_refcnt: 5.
[ 113.671806] neigh_parms_destroy: parms: ffff81003efc7210, dev: eth0, dev_refcnt: 3.
[ 123.916250] unregister_netdevice: waiting for eth0 to become free. Usage count = 1
GC hits us:
[ 124.839572] neigh_destroy: parms: ffff81003d8e8df0, dev: eth0, refcnt: 1, dev_refcnt: 11.
[ 124.847813] neigh_parms_destroy: parms: ffff81003d8e8df0, dev: eth0, dev_refcnt: 1.
[ 124.952026] ACPI: PCI interrupt for device 0000:02:0d.0 disabled
--
Evgeniy Polyakov
next prev parent reply other threads:[~2008-01-21 12:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-9778-10286@http.bugzilla.kernel.org/>
2008-01-20 0:58 ` [Bugme-new] [Bug 9778] New: unregister_netdevice: waiting for [device] to become free Andrew Morton
2008-01-20 10:30 ` David Miller
2008-01-21 12:14 ` Evgeniy Polyakov [this message]
2008-01-21 12:36 ` David Miller
2008-01-21 14:36 ` Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080121121445.GA29459@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nigel@suspend2.net \
--cc=xemul@openvz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.