1. 06 3月, 2008 1 次提交
  2. 05 3月, 2008 3 次提交
  3. 04 3月, 2008 8 次提交
  4. 01 3月, 2008 11 次提交
  5. 29 2月, 2008 14 次提交
  6. 27 2月, 2008 2 次提交
    • P
      [INET]: Don't create tunnels with '%' in name. · b37d428b
      Pavel Emelyanov 提交于
      Four tunnel drivers (ip_gre, ipip, ip6_tunnel and sit) can receive a
      pre-defined name for a device from the userspace.  Since these drivers
      call the register_netdevice() (rtnl_lock, is held), which does _not_
      generate the device's name, this name may contain a '%' character.
      
      Not sure how bad is this to have a device with a '%' in its name, but
      all the other places either use the register_netdev(), which call the
      dev_alloc_name(), or explicitly call the dev_alloc_name() before
      registering, i.e. do not allow for such names.
      
      This had to be prior to the commit 34cc7b, but I forgot to number the
      patches and this one got lost, sorry.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b37d428b
    • B
      [IPV4]: Reset scope when changing address · 148f9729
      Bjorn Mork 提交于
      This bug did bite at least one user, who did have to resort to rebooting
      the system after an "ifconfig eth0 127.0.0.1" typo.
      
      Deleting the address and adding a new is a less intrusive workaround.
      But I still beleive this is a bug that should be fixed.  Some way or
      another.
      
      Another possibility would be to remove the scope mangling based on
      address.  This will always be incomplete (are 127/8 the only address
      space with host scope requirements?)
      
      We set the scope to RT_SCOPE_HOST if an IPv4 interface is configured
      with a loopback address (127/8).  The scope is never reset, and will
      remain set to RT_SCOPE_HOST after changing the address. This patch
      resets the scope if the address is changed again, to restore normal
      functionality.
      Signed-off-by: NBjorn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      148f9729
  7. 24 2月, 2008 1 次提交