* [PATCH] [ROSE] rose node number was never decreased
@ 2010-08-26 22:15 Bernard F6BVP
2010-08-26 23:09 ` David Miller
0 siblings, 1 reply; 2+ messages in thread
From: Bernard F6BVP @ 2010-08-26 22:15 UTC (permalink / raw)
To: ralf; +Cc: davem, linux-hams, netdev, bpidoux
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
When a ROSE node was deleted, node number was not
decremented and addr kept going up when a new node
was added.
/proc/net/rose_neigh
addr callsign dev count use mode restart t0 tf digipeaters
00007 F5KBW-9 ax0 1 0 DTE no 0 0
00006 F6BVP-11 ax0 2 0 DTE no 0 0
00005 F6BVP-9 ax0 2 0 DTE no 0 0
00001 RSLOOP-0 ??? 0 0 DCE yes 0 0
With this patch, rose node number is correctly decreased
when nodes are deleted and new ones added :
/proc/net/rose_neigh
addr callsign dev count use mode restart t0 tf digipeaters
00004 F5KBW-9 ax0 1 0 DTE no 0 0
00003 F6BVP-11 ax0 2 0 DTE no 0 0
00002 F6BVP-9 ax0 2 0 DTE no 0 0
00001 RSLOOP-0 ??? 0 0 DCE yes 0 0
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
[-- Attachment #2: rose_route.patch --]
[-- Type: text/x-patch, Size: 427 bytes --]
--- a/net/rose/rose_route.c 2010-08-13 22:44:56.000000000 +0200
+++ b/net/rose/rose_route.c 2010-08-26 15:11:13.000000000 +0200
@@ -240,6 +240,7 @@
ax25_cb_put(rose_neigh->ax25);
kfree(rose_neigh->digipeat);
kfree(rose_neigh);
+ rose_neigh_no--;
return;
}
@@ -250,6 +251,7 @@
ax25_cb_put(rose_neigh->ax25);
kfree(rose_neigh->digipeat);
kfree(rose_neigh);
+ rose_neigh_no--;
return;
}
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] [ROSE] rose node number was never decreased
2010-08-26 22:15 [PATCH] [ROSE] rose node number was never decreased Bernard F6BVP
@ 2010-08-26 23:09 ` David Miller
0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2010-08-26 23:09 UTC (permalink / raw)
To: f6bvp; +Cc: ralf, linux-hams, netdev, bpidoux
From: Bernard F6BVP <f6bvp@free.fr>
Date: Fri, 27 Aug 2010 00:15:01 +0200
> When a ROSE node was deleted, node number was not
> decremented and addr kept going up when a new node
> was added.
>
> /proc/net/rose_neigh
> addr callsign dev count use mode restart t0 tf digipeaters
> 00007 F5KBW-9 ax0 1 0 DTE no 0 0
> 00006 F6BVP-11 ax0 2 0 DTE no 0 0
> 00005 F6BVP-9 ax0 2 0 DTE no 0 0
> 00001 RSLOOP-0 ??? 0 0 DCE yes 0 0
>
> With this patch, rose node number is correctly decreased
> when nodes are deleted and new ones added :
>
> /proc/net/rose_neigh
> addr callsign dev count use mode restart t0 tf digipeaters
> 00004 F5KBW-9 ax0 1 0 DTE no 0 0
> 00003 F6BVP-11 ax0 2 0 DTE no 0 0
> 00002 F6BVP-9 ax0 2 0 DTE no 0 0
> 00001 RSLOOP-0 ??? 0 0 DCE yes 0 0
>
> Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
I don't see how this patch is correct.
The whole point of the rose_neigh_no seems to be to make sure
that unique numbers are given to the neighbours.
But with your patch, we can end up easily with neighbours assigned the
same number. Consider adding 3 nodes, and let's say they get
rose_neigh_no 1, 2, and 3
A: neigh_no 1
B: neigh_no 2
C: neigh_no 3
Delete B, now rose_neigh_no with your patch applied will be '3'.
Next, add D, which will get neigh_no of '3' which is the same
as what C has.
This can't be right.
What the code wants is an allocation of unique IDs and a simple
bitmap along with find_next_zero_bit(), set_bit(), and clear_bit()
ought to do the trick.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-08-26 23:09 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-26 22:15 [PATCH] [ROSE] rose node number was never decreased Bernard F6BVP
2010-08-26 23:09 ` David Miller
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).