From: "Timo Teräs" <timo.teras@iki.fi>
To: netdev@vger.kernel.org
Subject: never disappearing neighbors with netlink arp
Date: Wed, 03 Jun 2009 21:35:02 +0300 [thread overview]
Message-ID: <4A26C256.9060606@iki.fi> (raw)
Hi,
I found a very peculiar problem related to neighbor cache when using the
netlink arp api. I never noticed this earlier until recently one of the nodes
with a lot of traffic started getting "Neighbour table overflow" messages.
I made my opennhrp daemon reply immediately with NUD_INVALID if the address is
known to be unreachable which sounds like the proper thing to do.
However, after some tedious reading of sources, it looks that:
1. Packet triggers new neighbor solicitation, entry goes to NUD_INCOMPLETE,
the skb gets queued and based on my neightable config the first solicit
is sent directly via netlink.
2. Userland receives and sends immediately back an update to NUD_INVALID.
3. Now it looks like net/core/neighbour.c:neigh_update() first checks for
!(new & NUD_VALID), this matches and does the state transition, but the
queued skb:s are not dequeued / error reported. Which leaves refs to the
neigh entry.
Now what happens after this is still a bit unclear to me, but it looks like
the entry never gets garbage collected after this.
I can probably workaround this from userland by just not replying at all
for non-existent neighbors. But what would be the proper fix for this?
It sounds bad if userland can flood never expiring entries to kernel.
Would just a simple skb queue flush / error reporting be enough? Do we
need to update time stamps too? Do something additional?
Cheers,
Timo
reply other threads:[~2009-06-03 19:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4A26C256.9060606@iki.fi \
--to=timo.teras@iki.fi \
--cc=netdev@vger.kernel.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.