aboutsummaryrefslogtreecommitdiffstats
path: root/net/decnet/dn_neigh.c
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2008-01-24 03:13:18 -0500
committerDavid S. Miller <davem@davemloft.net>2008-01-28 18:00:03 -0500
commit426b5303eb435d98b9bee37a807be386bc2b3320 (patch)
tree86f7bd945101d9ac51afb22a210d22b8ff956a4e /net/decnet/dn_neigh.c
parente1af9f270b69a3ad1dcbabb404dd1f40a96f43f5 (diff)
[NETNS]: Modify the neighbour table code so it handles multiple network namespaces
I'm actually surprised at how much was involved. At first glance it appears that the neighbour table data structures are already split by network device so all that should be needed is to modify the user interface commands to filter the set of neighbours by the network namespace of their devices. However a couple things turned up while I was reading through the code. The proxy neighbour table allows entries with no network device, and the neighbour parms are per network device (except for the defaults) so they now need a per network namespace default. So I updated the two structures (which surprised me) with their very own network namespace parameter. Updated the relevant lookup and destroy routines with a network namespace parameter and modified the code that interacts with users to filter out neighbour table entries for devices of other namespaces. I'm a little concerned that we can modify and display the global table configuration and from all network namespaces. But this appears good enough for now. I keep thinking modifying the neighbour table to have per network namespace instances of each table type would should be cleaner. The hash table is already dynamically sized so there are it is not a limiter. The default parameter would be straight forward to take care of. However when I look at the how the network table is built and used I still find some assumptions that there is only a single neighbour table for each type of table in the kernel. The netlink operations, neigh_seq_start, the non-core network users that call neigh_lookup. So while it might be doable it would require more refactoring than my current approach of just doing a little extra filtering in the code. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/decnet/dn_neigh.c')
-rw-r--r--net/decnet/dn_neigh.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c
index e851b143cca3..1ca13b17974d 100644
--- a/net/decnet/dn_neigh.c
+++ b/net/decnet/dn_neigh.c
@@ -580,8 +580,8 @@ static const struct seq_operations dn_neigh_seq_ops = {
580 580
581static int dn_neigh_seq_open(struct inode *inode, struct file *file) 581static int dn_neigh_seq_open(struct inode *inode, struct file *file)
582{ 582{
583 return seq_open_private(file, &dn_neigh_seq_ops, 583 return seq_open_net(inode, file, &dn_neigh_seq_ops,
584 sizeof(struct neigh_seq_state)); 584 sizeof(struct neigh_seq_state));
585} 585}
586 586
587static const struct file_operations dn_neigh_seq_fops = { 587static const struct file_operations dn_neigh_seq_fops = {
@@ -589,7 +589,7 @@ static const struct file_operations dn_neigh_seq_fops = {
589 .open = dn_neigh_seq_open, 589 .open = dn_neigh_seq_open,
590 .read = seq_read, 590 .read = seq_read,
591 .llseek = seq_lseek, 591 .llseek = seq_lseek,
592 .release = seq_release_private, 592 .release = seq_release_net,
593}; 593};
594 594
595#endif 595#endif