On Tue, 2007-04-17 at 14:58 +0200, Patrick McHardy wrote:
> David Miller wrote:
> > From: Patrick McHardy <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
