1. 14 Jul, 2008 1 commit
  2. 09 Jul, 2008 1 commit
  3. 08 May, 2008 1 commit
    • Patrick McHardy's avatar
      macvlan: Fix memleak on device removal/crash on module removal · 73120964
      Patrick McHardy authored
      As noticed by Ben Greear, macvlan crashes the kernel when unloading the
      module. The reason is that it tries to clean up the macvlan_port pointer
      on the macvlan device itself instead of the underlying device. A non-NULL
      pointer is taken as indication that the macvlan_handle_frame_hook is
      valid, when receiving the next packet on the underlying device it tries
      to call the NULL hook and crashes.
      Clean up the macvlan_port on the correct device to fix this.
      Signed-off-by; Patrick McHardy <kaber@trash.net>
      Tested-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 25 Mar, 2008 1 commit
  5. 31 Jan, 2008 1 commit
  6. 28 Jan, 2008 3 commits
  7. 10 Jan, 2008 1 commit
  8. 14 Oct, 2007 1 commit
  9. 10 Oct, 2007 4 commits
    • Stephen Hemminger's avatar
      [NET]: Move hardware header operations out of netdevice. · 3b04ddde
      Stephen Hemminger authored
      Since hardware header operations are part of the protocol class
      not the device instance, make them into a separate object and
      save memory.
      Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Stephen Hemminger's avatar
      [NET]: Wrap netdevice hardware header creation. · 0c4e8581
      Stephen Hemminger authored
      Add inline for common usage of hardware header creation, and
      fix bug in IPV6 mcast where the assumption about negative return is
      an errno. Negative return from hard_header means not enough space
      was available,(ie -N bytes).
      Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jeff Garzik's avatar
      [ETHTOOL] Provide default behaviors for a few ethtool sub-ioctls · 88d3aafd
      Jeff Garzik authored
      For the operations
      the default ethtool_op_xxx behavior is fine for all drivers, so we
      permit op==NULL to imply the default behavior.
      This provides a more uniform behavior across all drivers, eliminating
      ethtool(8) "ioctl not supported" errors on older drivers that had
      not been updated for the latest sub-ioctls.
      The ethtool_op_xxx() functions are left exported, in case anyone
      wishes to call them directly from a driver-private implementation --
      a not-uncommon case.  Should an ethtool_op_xxx() helper remain unused
      for a while, except by net/core/ethtool.c, we can un-export it at a
      later date.
      [ Resolved conflicts with set/get value ethtool patch... -DaveM ]
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric W. Biederman's avatar
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman authored
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      were modified to take a network namespace argument, and
      deal with it.
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      For now the ifindex generator is left global.
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 14 Jul, 2007 1 commit