From: Patrick McHardy <kaber@trash.net>
To: Ben Greear <greearb@candelatech.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Thomas Graf <tgraf@suug.ch>,
Robert.Olsson@data.slu.se
Subject: Re: [RFC NET 00/04]: Increase number of possible routing tables
Date: Fri, 07 Jul 2006 21:58:31 +0200 [thread overview]
Message-ID: <44AEBCE7.2030203@trash.net> (raw)
In-Reply-To: <44AEA462.1080505@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Ben Greear wrote:
> Patrick McHardy wrote:
>
>>> I took on Ben's challenge to increase the number of possible routing
>>> tables, these are the resulting patches.
>
>
> I am seeing problems..though they could be with the way I'm using the tool
> or pehaps I patched the kernel incorrectly.
>
> I applied the 3 patches to 2.6.17..all patches applied without problem,
> but with a few lines of fuzz. I get the same behaviour with and
> without the new 'ip' patches applied.
>
> If I do an 'ip ru show', then I see lots of tables, though not all it
> seems. (I have not tried beyond 205 yet). But, if I do an
> 'ip route show table XX', then I see nothing or incorrect values.
My patches introduced a bug when dumping tables which could lead to
incorrect routes beeing dumped. A second bug (that already existed)
makes the kernel fail when dumping more rules than fit in a skb.
I think I've already seen the patch to address the second problem
a short time ago sent by someone else. Anyway, this patch should
fix both.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1526 bytes --]
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 3c49e6b..6e1aaa4 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -357,6 +357,7 @@ int inet_dump_fib(struct sk_buff *skb, s
unsigned int e = 0, s_e;
struct fib_table *tb;
struct hlist_node *node;
+ int dumped = 0;
if (NLMSG_PAYLOAD(cb->nlh, 0) >= sizeof(struct rtmsg) &&
((struct rtmsg*)NLMSG_DATA(cb->nlh))->rtm_flags&RTM_F_CLONED)
@@ -365,16 +366,17 @@ int inet_dump_fib(struct sk_buff *skb, s
s_h = cb->args[0];
s_e = cb->args[1];
- for (h = s_h; h < FIB_TABLE_HASHSZ; h++) {
+ for (h = s_h; h < FIB_TABLE_HASHSZ; h++, s_e = 0) {
e = 0;
hlist_for_each_entry(tb, node, &fib_table_hash[h], tb_hlist) {
if (e < s_e)
goto next;
- if (e > s_e)
- memset(&cb->args[1], 0, sizeof(cb->args) -
+ if (dumped)
+ memset(&cb->args[2], 0, sizeof(cb->args) -
2 * sizeof(cb->args[0]));
if (tb->tb_dump(tb, skb, cb) < 0)
goto out;
+ dumped = 1;
next:
e++;
}
diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
index a41ab4b..6f33f12 100644
--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -459,13 +459,13 @@ int inet_dump_rules(struct sk_buff *skb,
rcu_read_lock();
hlist_for_each_entry(r, node, &fib_rules, hlist) {
-
if (idx < s_idx)
- continue;
+ goto next;
if (inet_fill_rule(skb, r, NETLINK_CB(cb->skb).pid,
cb->nlh->nlmsg_seq,
RTM_NEWRULE, NLM_F_MULTI) < 0)
break;
+next:
idx++;
}
rcu_read_unlock();
next prev parent reply other threads:[~2006-07-07 19:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-03 7:52 [RFC NET 00/04]: Increase number of possible routing tables Patrick McHardy
2006-07-03 7:53 ` [RFC NET 01/04]: Use u32 for routing table IDs Patrick McHardy
2006-07-03 7:53 ` [RFC NET 02/04]: Introduce RTA_TABLE routing attribute Patrick McHardy
2006-07-03 7:53 ` [RFC IPV4 03/04]: Increase number of possible routing tables to 2^32 Patrick McHardy
2006-07-03 7:53 ` [RFC DECNET 04/04]: " Patrick McHardy
2006-07-03 11:20 ` Steven Whitehouse
2006-07-03 11:21 ` Patrick McHardy
2006-07-03 9:23 ` [RFC NET 00/04]: Increase number of possible routing tables Patrick McHardy
2006-07-03 9:38 ` Patrick McHardy
2006-07-03 11:34 ` Thomas Graf
2006-07-03 11:36 ` Patrick McHardy
2006-07-03 11:41 ` Thomas Graf
2006-07-07 8:05 ` Patrick McHardy
2006-07-07 18:13 ` Ben Greear
2006-07-07 19:58 ` Patrick McHardy [this message]
2006-07-07 23:59 ` David Miller
2006-07-08 2:45 ` Patrick McHardy
2006-07-08 1:07 ` Ben Greear
2006-07-08 2:48 ` Patrick McHardy
2006-07-08 5:06 ` Ben Greear
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=44AEBCE7.2030203@trash.net \
--to=kaber@trash.net \
--cc=Robert.Olsson@data.slu.se \
--cc=davem@davemloft.net \
--cc=greearb@candelatech.com \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/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;
as well as URLs for NNTP newsgroup(s).