1. 06 Dec, 2012 3 commits
  2. 05 Dec, 2012 10 commits
  3. 04 Dec, 2012 24 commits
  4. 03 Dec, 2012 3 commits
    • David S. Miller's avatar
      Merge tag 'dev_removal' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/net-next · 682d7978
      David S. Miller authored
      Networking:  Remove __dev* markings from the networking drivers
      
      This is a series of patches that remove the dev* attributes for all
      networking drivers, with the exception of wireless drivers, those are in
      a different branch.
      
      Use of __devinit, __devexit_p, __devinitdata, __devinitconst, and
      __devexit are no longer needed since CONFIG_HOTPLUG is being removed as
      an option.
      
      Note, there are some devinit compiler section mismatch warnings due to
      this series, but they are fixed up when merged with my driver-next
      branch, which fixes the PCI device id warnings, and removes the modpost
      detection, as it's no longer needed.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      682d7978
    • Paul Marks's avatar
      ipv6: Fix default route failover when CONFIG_IPV6_ROUTER_PREF=n · a5a81f0b
      Paul Marks authored
      I believe this commit from 2008 was incorrect:
      http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=398bcbebb6f721ac308df1e3d658c0029bb74503
      
      When CONFIG_IPV6_ROUTER_PREF is disabled, the kernel should follow
      RFC4861 section 6.3.6: if no route is NUD_VALID, then traffic should be
      sprayed across all routers (indirectly triggering NUD) until one of them
      becomes NUD_VALID.
      
      However, the following experiment demonstrates that this does not work:
      
      1) Connect to an IPv6 network.
      2) Change the router's MAC (and link-local) address.
      
      The kernel will lock onto the first router and never try the new one, even
      if the first becomes unreachable.  This patch fixes the problem by
      allowing rt6_check_neigh() to return 0; if all routers return 0, then
      rt6_select() will fall back to round-robin behavior.
      
      This patch should have no effect when CONFIG_IPV6_ROUTER_PREF=y.
      
      Note that rt6_check_neigh() is only used in a boolean context, so I've
      changed its return type accordingly.
      Signed-off-by: default avatarPaul Marks <pmarks@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5a81f0b
    • Michael S. Tsirkin's avatar
      tun: only queue packets on device · 5d097109
      Michael S. Tsirkin authored
      Historically tun supported two modes of operation:
      - in default mode, a small number of packets would get queued
        at the device, the rest would be queued in qdisc
      - in one queue mode, all packets would get queued at the device
      
      This might have made sense up to a point where we made the
      queue depth for both modes the same and set it to
      a huge value (500) so unless the consumer
      is stuck the chance of losing packets is small.
      
      Thus in practice both modes behave the same, but the
      default mode has some problems:
      - if packets are never consumed, fragments are never orphaned
        which cases a DOS for sender using zero copy transmit
      - overrun errors are hard to diagnose: fifo error is incremented
        only once so you can not distinguish between
        userspace that is stuck and a transient failure,
        tcpdump on the device does not show any traffic
      
      Userspace solves this simply by enabling IFF_ONE_QUEUE
      but there seems to be little point in not doing the
      right thing for everyone, by default.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d097109