1. 13 8月, 2011 1 次提交
  2. 04 8月, 2011 1 次提交
  3. 21 6月, 2011 1 次提交
  4. 10 6月, 2011 1 次提交
  5. 07 6月, 2011 1 次提交
  6. 19 5月, 2011 1 次提交
  7. 14 4月, 2011 1 次提交
  8. 31 3月, 2011 1 次提交
    • J
      drivers/net: Remove IRQF_SAMPLE_RANDOM flag from network drivers · ab392d2d
      Javier Martinez Canillas 提交于
      The IRQF_SAMPLE_RANDOM flag is marked as deprecated and will be removed.
      
      Every input point to the kernel's entropy pool have to better document the
      type of entropy source it is.
      
      drivers/char/random.c now implements a set of interfaces that can be used for
      devices to collect enviromental noise. IRQF_SAMPLE_RANDOM will be replaced
      with these add_*_randomness exported functions.
      
      Network drivers are not a good source of entropy. They use as a source of
      entropy essentially a remote host. Which means that the source of entropy can
      be potentially controlled by an attacker. Also, with heavy workloads the
      entropy decreases due to less hardware interrupts happening thanks to irq
      mitigation and NAPI.
      
      If a system relies in its network interface as a entropy source it has a false
      sense of security. Systems that don't have devices whose drivers are good
      sources of entropy, should either use a hardware random number generator or
      feed the kernel's entropy pool from userspace using other sources of entropy
      such as EGD, video_entropyd, timer_entropyd and audio-entropyd.
      Signed-off-by: NJavier Martinez Canillas <martinez.javier@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab392d2d
  9. 01 3月, 2011 1 次提交
    • J
      macb: don't use platform_set_drvdata() on a net_device · 91523947
      Jamie Iles 提交于
      Commit 71d64290 (Driver core: convert platform_{get,set}_drvdata to
      static inline functions) now triggers a warning in the macb network
      driver:
      
        CC      drivers/net/macb.o
      drivers/net/macb.c: In function ‘macb_mii_init’:
      drivers/net/macb.c:263: warning: passing argument 1 of ‘platform_set_drvdata’ from incompatible pointer type
      include/linux/platform_device.h:138: note: expected ‘struct platform_device *’ but argument is of type ‘struct net_device *’
      
      Use dev_set_drvdata() on the device embedded in the net_device instead.
      
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NJamie Iles <jamie@jamieiles.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      91523947
  10. 26 10月, 2010 1 次提交
    • J
      macb: Don't re-enable interrupts while in polling mode · b336369c
      Joshua Hoke 提交于
      On a busy network, the macb driver could get stuck in the interrupt
      handler, quickly triggering the watchdog, due to a confluence of
      factors:
      
       1. macb_poll re-enables interrupts unconditionally, even when it will
          be called again because it exhausted its rx budget
      
       2. macb_interrupt only disables interrupts after scheduling
          macb_poll, but scheduling fails when macb_poll is already scheduled
          because it didn't call napi_complete
      
       3. macb_interrupt loops until the interrupt status register is clear,
          which will never happen in this case if the driver doesn't disable
          the RX interrupt
      
      Since macb_interrupt runs in interrupt context, this effectively locks
      up the machine, triggering the hardware watchdog.
      
      This issue was readily reproducible on a flooded network with a
      modified 2.6.27.48 kernel. The same problem appears to still be in the
      2.6.36-rc8 driver code, so I am submitting this patch against that
      version. I have not tested this version of the patch except to make
      sure the kernel compiles.
      Signed-off-by: NJoshua Hoke <joshua.hoke@sixnet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b336369c
  11. 03 9月, 2010 1 次提交
  12. 19 7月, 2010 1 次提交
  13. 10 5月, 2010 1 次提交
  14. 08 4月, 2010 1 次提交
  15. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko 提交于
      Converts the list and the core manipulating with it to be the same as uc_list.
      
      +uses two functions for adding/removing mc address (normal and "global"
       variant) instead of a function parameter.
      +removes dev_mcast.c completely.
      +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
       manipulation with lists on a sandbox (used in bonding and 80211 drivers)
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  16. 26 2月, 2010 1 次提交
  17. 13 2月, 2010 2 次提交
  18. 21 9月, 2009 1 次提交
  19. 02 9月, 2009 1 次提交
  20. 24 8月, 2009 1 次提交
  21. 06 7月, 2009 1 次提交
  22. 13 6月, 2009 1 次提交
  23. 05 5月, 2009 1 次提交
  24. 17 4月, 2009 2 次提交
  25. 14 4月, 2009 1 次提交
  26. 25 3月, 2009 2 次提交
  27. 27 1月, 2009 1 次提交
  28. 22 1月, 2009 1 次提交
  29. 20 1月, 2009 1 次提交
    • R
      macb: avoid lockup when TGO during underrun · 39eddb4c
      Richard Röjfors 提交于
      In rare cases when an underrun occur, all macb buffers where consumed
      and the netif_queue was stopped infinitely. This happens then the TGO
      (transfer ongoing) bit in the TSR is set (and UND). It seems like
      clening up after the underrun makes the driver and the macb hardware
      end up in an inconsistent state. The result of this is that in the
      following calls to macb_tx no TX buffers are released -> the
      netif_queue was stopped, and never woken up again.
      
      The solution is to disable the transmitter, if TGO is set, before
      clening up after the underrun, and re-enable the transmitter when the
      cleaning up is done.
      Signed-off-by: NRichard Röjfors <richard.rojfors@endian.se>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39eddb4c
  30. 23 12月, 2008 1 次提交
  31. 04 11月, 2008 1 次提交
  32. 28 10月, 2008 1 次提交
  33. 09 10月, 2008 2 次提交
  34. 07 8月, 2008 1 次提交
  35. 23 7月, 2008 1 次提交
    • A
      netdev: bunch of drivers: avoid WARN at net/core/dev.c:1328 · c8f15686
      Anton Vorontsov 提交于
      The drivers were touching net queue before it has been started, so
      without this patch, the drivers will potentially WARN at
      net/core/dev.c:1328.
      
      I don't have the hardware for the drivers below, so this patch is
      untested, and thus should be carefully peer reviewed.
      
      tc35815.c
      au1000_eth.c
      bfin_mac.c
      macb.c
      ^ The four drivers are using phylib, they're calling netif_start_queue()
      in open() callback. So trivially remove netif_tx_schedule_all().
      Phylib will handle netif_carrier_*().
      
      cpmac.c
      fec_mpc52xx.c
      fs_enet/fs_enet-main.c
      sh_eth.c
      ^ The same as above, but these were also needlessly calling
      netif_carrier_*() functions. So removed queue calls and also remove
      carrier calls, since phylib will handle it. fs_enet-main.c also didn't
      call netif_start_queue() at open(), this is fixed now.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8f15686
  36. 18 7月, 2008 1 次提交