1. 25 1月, 2017 1 次提交
  2. 13 10月, 2016 1 次提交
    • J
      net: deprecate eth_change_mtu, remove usage · a52ad514
      Jarod Wilson 提交于
      With centralized MTU checking, there's nothing productive done by
      eth_change_mtu that isn't already done in dev_set_mtu, so mark it as
      deprecated and remove all usage of it in the kernel. All callers have been
      audited for calls to alloc_etherdev* or ether_setup directly, which means
      they all have a valid dev->min_mtu and dev->max_mtu. Now eth_change_mtu
      prints out a netdev_warn about being deprecated, for the benefit of
      out-of-tree drivers that might be utilizing it.
      
      Of note, dvb_net.c actually had dev->mtu = 4096, while using
      eth_change_mtu, meaning that if you ever tried changing it's mtu, you
      couldn't set it above 1500 anymore. It's now getting dev->max_mtu also set
      to 4096 to remedy that.
      
      v2: fix up lantiq_etop, missed breakage due to drive not compiling on x86
      
      CC: netdev@vger.kernel.org
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a52ad514
  3. 28 10月, 2015 1 次提交
  4. 18 9月, 2015 1 次提交
  5. 02 6月, 2014 3 次提交
  6. 25 5月, 2014 3 次提交
  7. 14 5月, 2014 1 次提交
  8. 24 3月, 2014 1 次提交
  9. 17 4月, 2013 1 次提交
  10. 09 4月, 2013 2 次提交
  11. 08 4月, 2013 1 次提交
  12. 30 3月, 2013 1 次提交
  13. 30 1月, 2013 1 次提交
  14. 04 1月, 2013 1 次提交
  15. 04 12月, 2012 1 次提交
  16. 17 7月, 2012 1 次提交
  17. 12 5月, 2012 1 次提交
  18. 22 4月, 2012 2 次提交
    • M
      ks8851: Fix request_irq/free_irq mismatch · e8195b24
      Matt Renzelmann 提交于
      The dev_id parameter passed to free_irq needs to match the one passed
      to the corresponding request_irq.
      Signed-off-by: NMatt Renzelmann <mjr@cs.wisc.edu>
      Acked-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8195b24
    • S
      ks8851: Fix mutex deadlock in ks8851_net_stop() · c5a99937
      Stephen Boyd 提交于
      There is a potential deadlock scenario when the ks8851 driver
      is removed. The interrupt handler schedules a workqueue which
      acquires a mutex that ks8851_net_stop() also acquires before
      flushing the workqueue. Previously lockdep wouldn't be able
      to find this problem but now that it has the support we can
      trigger this lockdep warning by rmmoding the driver after
      an ifconfig up.
      
      Fix the possible deadlock by disabling the interrupts in
      the chip and then release the lock across the workqueue
      flushing. The mutex is only there to proect the registers
      anyway so this should be ok.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      3.0.21-00021-g8b33780-dirty #2911
      -------------------------------------------------------
      rmmod/125 is trying to acquire lock:
       ((&ks->irq_work)){+.+...}, at: [<c019e0b8>] flush_work+0x0/0xac
      
      but task is already holding lock:
       (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&ks->lock){+.+...}:
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c083dbec>] mutex_lock_nested+0x68/0x3dc
             [<bf00bd48>] ks8851_irq_work+0x24/0x46c [ks8851]
             [<c019c580>] process_one_work+0x2d8/0x518
             [<c019cb98>] worker_thread+0x220/0x3a0
             [<c01a2ad4>] kthread+0x88/0x94
             [<c0107008>] kernel_thread_exit+0x0/0x8
      
      -> #0 ((&ks->irq_work)){+.+...}:
             [<c01b7984>] validate_chain+0x914/0x1018
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c019e104>] flush_work+0x4c/0xac
             [<bf00b858>] ks8851_net_stop+0x6c/0x138 [ks8851]
             [<c06b209c>] __dev_close_many+0x98/0xcc
             [<c06b2174>] dev_close_many+0x68/0xd0
             [<c06b22ec>] rollback_registered_many+0xcc/0x2b8
             [<c06b2554>] rollback_registered+0x28/0x34
             [<c06b25b8>] unregister_netdevice_queue+0x58/0x7c
             [<c06b25f4>] unregister_netdev+0x18/0x20
             [<bf00c1f4>] ks8851_remove+0x64/0xb4 [ks8851]
             [<c049ddf0>] spi_drv_remove+0x18/0x1c
             [<c0468e98>] __device_release_driver+0x7c/0xbc
             [<c0468f64>] driver_detach+0x8c/0xb4
             [<c0467f00>] bus_remove_driver+0xb8/0xe8
             [<c01c1d20>] sys_delete_module+0x1e8/0x27c
             [<c0105ec0>] ret_fast_syscall+0x0/0x3c
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&ks->lock);
                                     lock((&ks->irq_work));
                                     lock(&ks->lock);
        lock((&ks->irq_work));
      
       *** DEADLOCK ***
      
      4 locks held by rmmod/125:
       #0:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f44>] driver_detach+0x6c/0xb4
       #1:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f50>] driver_detach+0x78/0xb4
       #2:  (rtnl_mutex){+.+.+.}, at: [<c06b25e8>] unregister_netdev+0xc/0x20
       #3:  (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5a99937
  19. 14 4月, 2012 1 次提交
  20. 16 2月, 2012 1 次提交
  21. 14 2月, 2012 1 次提交
  22. 13 2月, 2012 1 次提交
  23. 01 2月, 2012 1 次提交
  24. 31 1月, 2012 1 次提交
  25. 27 11月, 2011 3 次提交
  26. 12 8月, 2011 1 次提交
  27. 07 6月, 2011 1 次提交
  28. 31 3月, 2011 1 次提交
  29. 09 11月, 2010 1 次提交
  30. 09 9月, 2010 1 次提交
  31. 06 5月, 2010 2 次提交