From: "Milan Kocián" <milon@wq.cz>
To: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>,
akpm@linux-foundation.org, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org
Subject: Re: [Bugme-new] [Bug 8320] New: replacing route in kernel doesn't send netlink message
Date: Wed, 18 Apr 2007 14:48:07 +0200 [thread overview]
Message-ID: <1176900487.8348.36.camel@nt.wq.cz> (raw)
In-Reply-To: <4624C46D.1030609@trash.net>
On Tue, 2007-04-17 at 14:58 +0200, Patrick McHardy wrote:
> David Miller wrote:
> > From: Patrick McHardy <kaber@trash.net>
> > Date: Mon, 16 Apr 2007 06:59:06 +0200
> >
> >
> >>RTM_DELROUTE + RTM_NEWROUTE seem to be safer, although you're correct
> >>that it might cause userspace to perform some action upon receiving
> >>the DELROUTE message since the update is non-atomic. So I really don't
> >>know, I'm in favour of having notifications for replacements, but I
> >>fear we might break something.
> >
> >
> > We can cry foul about a broken application if an application following
> > the API correctly would interpret the new messages correctly.
> >
> > I think it doesn't make sense to do a delete then a newroute for
> > the atomicity issues, and therefore the replace makes the most
> > sense as long as existing correct uses of the API would not
> > explode on this.
>
> They shouldn't, worst case is that they ignore NLM_F_REPLACE and treat
> it as a completely new route, which is at least half way correct and
> not really worse than today.
>
> Milan, could you cook up another patch which uses NLM_F_REPLACE?
>
I can try it. Output is in patch below. Review carefully. I don't know
if it's best approach. It's tested and working without problem
(probably :-))
--- net/ipv4.old/fib_hash.c 2007-04-18 12:50:11.000000000 +0200
+++ net/ipv4/fib_hash.c 2007-04-18 12:39:49.081369320 +0200
@@ -443,7 +443,6 @@
if (cfg->fc_nlflags & NLM_F_REPLACE) {
struct fib_info *fi_drop;
u8 state;
-
write_lock_bh(&fib_hash_lock);
fi_drop = fa->fa_info;
fa->fa_info = fi;
@@ -457,6 +456,8 @@
fib_release_info(fi_drop);
if (state & FA_S_ACCESSED)
rt_cache_flush(-1);
+ rtmsg_fib(RTM_NEWROUTE, key, fa, cfg->fc_dst_len, tb->tb_id,
+ &cfg->fc_nlinfo, NLM_F_REPLACE);
return 0;
}
@@ -524,7 +525,7 @@
rt_cache_flush(-1);
rtmsg_fib(RTM_NEWROUTE, key, new_fa, cfg->fc_dst_len, tb->tb_id,
- &cfg->fc_nlinfo);
+ &cfg->fc_nlinfo, 0);
return 0;
out_free_new_fa:
@@ -590,7 +591,7 @@
fa = fa_to_delete;
rtmsg_fib(RTM_DELROUTE, key, fa, cfg->fc_dst_len,
- tb->tb_id, &cfg->fc_nlinfo);
+ tb->tb_id, &cfg->fc_nlinfo, 0);
kill_fn = 0;
write_lock_bh(&fib_hash_lock);
--- net/ipv4.old/fib_trie.c 2007-04-18 12:50:11.000000000 +0200
+++ net/ipv4/fib_trie.c 2007-04-18 12:42:29.423993536 +0200
@@ -1205,6 +1205,9 @@
fib_release_info(fi_drop);
if (state & FA_S_ACCESSED)
rt_cache_flush(-1);
+ rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen, tb->tb_id,
+ &cfg->fc_nlinfo, NLM_F_REPLACE);
+
goto succeeded;
}
/* Error if we find a perfect match which
@@ -1256,7 +1259,7 @@
rt_cache_flush(-1);
rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen, tb->tb_id,
- &cfg->fc_nlinfo);
+ &cfg->fc_nlinfo, 0);
succeeded:
return 0;
@@ -1599,7 +1602,7 @@
fa = fa_to_delete;
rtmsg_fib(RTM_DELROUTE, htonl(key), fa, plen, tb->tb_id,
- &cfg->fc_nlinfo);
+ &cfg->fc_nlinfo, 0);
l = fib_find_node(t, key);
li = find_leaf_info(l, plen);
--- net/ipv4.old/fib_semantics.c 2007-04-18 12:50:11.000000000 +0200
+++ net/ipv4/fib_semantics.c 2007-04-18 12:40:54.807377448 +0200
@@ -301,7 +301,7 @@
}
void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
- int dst_len, u32 tb_id, struct nl_info *info)
+ int dst_len, u32 tb_id, struct nl_info *info, unsigned int
nlm_flags)
{
struct sk_buff *skb;
u32 seq = info->nlh ? info->nlh->nlmsg_seq : 0;
@@ -313,7 +313,7 @@
err = fib_dump_info(skb, info->pid, seq, event, tb_id,
fa->fa_type, fa->fa_scope, key, dst_len,
- fa->fa_tos, fa->fa_info, 0);
+ fa->fa_tos, fa->fa_info, nlm_flags);
/* failure implies BUG in fib_nlmsg_size() */
BUG_ON(err < 0);
--- net/ipv4.old/fib_lookup.h 2007-04-18 12:50:11.000000000 +0200
+++ net/ipv4/fib_lookup.h 2007-04-18 12:43:42.377902856 +0200
@@ -30,7 +30,7 @@
int dst_len, u8 tos, struct fib_info *fi,
unsigned int);
extern void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
- int dst_len, u32 tb_id, struct nl_info *info);
+ int dst_len, u32 tb_id, struct nl_info *info, unsigned int
nlm_flags);
extern struct fib_alias *fib_find_alias(struct list_head *fah,
u8 tos, u32 prio);
extern int fib_detect_death(struct fib_info *fi, int order,
--
Milan Kocián <milon@wq.cz>
next prev parent reply other threads:[~2007-04-18 12:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200704110937.l3B9b1Kp001053@fire-2.osdl.org>
2007-04-11 16:47 ` [Bugme-new] [Bug 8320] New: replacing route in kernel doesn't send netlink message Andrew Morton
2007-04-11 18:19 ` Patrick McHardy
2007-04-12 17:53 ` Milan Kocián
2007-04-16 4:59 ` Patrick McHardy
2007-04-17 0:10 ` David Miller
2007-04-17 12:58 ` Patrick McHardy
2007-04-18 12:48 ` Milan Kocián [this message]
2007-04-18 14:06 ` Patrick McHardy
2007-04-19 11:30 ` Milan Kocián
2007-04-19 12:12 ` Patrick McHardy
2007-04-19 21:42 ` Andrew Morton
2007-04-20 14:07 ` [patch 1/1] networking: fix sending netlink message when replace route Milan Kocian
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=1176900487.8348.36.camel@nt.wq.cz \
--to=milon@wq.cz \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--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 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).