netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>


  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).