From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
johunt@akamai.com, kaber@trash.net, dbavatar@gmail.com,
netdev@vger.kernel.org, yoshfuji@linux-ipv6.org,
jmorris@namei.org, pekkas@netcore.fi,
linux-kernel@vger.kernel.org,
Ben Greear <greearb@candelatech.com>
Subject: Re: Bug in net/ipv6/ip6_fib.c:fib6_dump_table()
Date: Sun, 24 Jun 2012 00:55:46 +0400 [thread overview]
Message-ID: <20120623205546.GA15964@ms2.inr.ac.ru> (raw)
In-Reply-To: <1340429851.4604.11942.camel@edumazet-glaptop>
On Sat, Jun 23, 2012 at 07:37:31AM +0200, Eric Dumazet wrote:
> All other /proc/net files don't have a such sophisticated walkers aware
> mechanism
I can explain why.
IPv6 routing table has a capital management drawback: core policy rules are mixed
with dynamic cache and addrconf routes in one structure.
(BTW it is one of reasons why I did not want to integrate routing cache to fib for IPv4)
Do you see the problem? F.e. when you do iptables-save, you do not expect
that it can occasionally miss some rules (unless you mess with it in parallel, of course)
The same is here. When you dump routing table, you are allowed to miss some cache routes,
but if you have a chance to miss at least one of important routes just because
unimportant dynamic part is alway under change, it is fatal.
There are a lot of ways to solve the problem, all of them have some flaws.
F.e. I can remember:
* atomic dump like bsd sysctl.
* keeping administrative routes in a separate list, which can be walked using skip/count
etc.
This way with walkers I chose because it looked quite optimal and because
it was an exciting little task for brains . :-)
> (easily DOSable by the way, if some guy opens 10.000 handles
> and suspend in the middle the dumps).
This is true. The easiest way to fix this is just to limit amount of readers,
putting them on hold.
Alexey
next prev parent reply other threads:[~2012-06-23 20:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-12 17:22 Debabrata Banerjee
2012-06-21 19:35 ` Josh Hunt
2012-06-21 20:27 ` Eric Dumazet
2012-06-21 21:50 ` Alexey Kuznetsov
2012-06-22 3:34 ` Gao feng
2012-06-22 6:49 ` Josh Hunt
2012-06-22 8:29 ` Eric Dumazet
2012-06-22 13:44 ` Josh Hunt
2012-06-22 18:13 ` Eric Dumazet
2012-06-22 21:12 ` Debabrata Banerjee
2012-06-23 0:02 ` David Miller
2012-06-23 5:37 ` Eric Dumazet
2012-06-23 20:55 ` Alexey Kuznetsov [this message]
2012-06-23 23:02 ` David Miller
2012-06-25 22:40 ` David Miller
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=20120623205546.GA15964@ms2.inr.ac.ru \
--to=kuznet@ms2.inr.ac.ru \
--cc=davem@davemloft.net \
--cc=dbavatar@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=greearb@candelatech.com \
--cc=jmorris@namei.org \
--cc=johunt@akamai.com \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pekkas@netcore.fi \
--cc=yoshfuji@linux-ipv6.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®