• Eric W. Biederman's avatar
    [NETNS]: Modify the neighbour table code so it handles multiple network namespaces · 426b5303
    Eric W. Biederman authored
    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: default avatarEric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: default avatarDaniel Lezcano <dlezcano@fr.ibm.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    426b5303
clip.c 25 KB