1. 24 Mar, 2011 2 commits
  2. 23 Mar, 2011 33 commits
  3. 22 Mar, 2011 5 commits
    • David S. Miller's avatar
    • Julian Anastasov's avatar
      ipv4: optimize route adding on secondary promotion · 04024b93
      Julian Anastasov authored
      Optimize the calling of fib_add_ifaddr for all
      secondary addresses after the promoted one to start from
      their place, not from the new place of the promoted
      secondary. It will save some CPU cycles because we
      are sure the promoted secondary was first for the subnet
      and all next secondaries do not change their place.
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04024b93
    • Julian Anastasov's avatar
      ipv4: remove the routes on secondary promotion · 2d230e2b
      Julian Anastasov authored
      The secondary address promotion relies on fib_sync_down_addr
      to remove all routes created for the secondary addresses when
      the old primary address is deleted. It does not happen for cases
      when the primary address is also in another subnet. Fix that
      by deleting local and broadcast routes for all secondaries while
      they are on device list and by faking that all addresses from
      this subnet are to be deleted. It relies on fib_del_ifaddr being
      able to ignore the IPs from the concerned subnet while checking
      for duplication.
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d230e2b
    • Julian Anastasov's avatar
      ipv4: fix route deletion for IPs on many subnets · e6abbaa2
      Julian Anastasov authored
      Alex Sidorenko reported for problems with local
      routes left after IP addresses are deleted. It happens
      when same IPs are used in more than one subnet for the
      device.
      
      	Fix fib_del_ifaddr to restrict the checks for duplicate
      local and broadcast addresses only to the IFAs that use
      our primary IFA or another primary IFA with same address.
      And we expect the prefsrc to be matched when the routes
      are deleted because it is possible they to differ only by
      prefsrc. This patch prevents local and broadcast routes
      to be leaked until their primary IP is deleted finally
      from the box.
      
      	As the secondary address promotion needs to delete
      the routes for all secondaries that used the old primary IFA,
      add option to ignore these secondaries from the checks and
      to assume they are already deleted, so that we can safely
      delete the route while these IFAs are still on the device list.
      Reported-by: default avatarAlex Sidorenko <alexandre.sidorenko@hp.com>
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6abbaa2
    • Julian Anastasov's avatar
      ipv4: match prefsrc when deleting routes · 74cb3c10
      Julian Anastasov authored
      fib_table_delete forgets to match the routes by prefsrc.
      Callers can specify known IP in fc_prefsrc and we should remove
      the exact route. This is needed for cases when same local or
      broadcast addresses are used in different subnets and the
      routes differ only in prefsrc. All callers that do not provide
      fc_prefsrc will ignore the route prefsrc as before and will
      delete the first occurence. That is how the ip route del default
      magic works.
      
      	Current callers are:
      
      - ip_rt_ioctl where rtentry_to_fib_config provides fc_prefsrc only
      when the provided device name matches IP label with colon.
      
      - inet_rtm_delroute where RTA_PREFSRC is optional too
      
      - fib_magic which deals with routes when deleting addresses
      and where the fc_prefsrc is always set with the primary IP
      for the concerned IFA.
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74cb3c10