1. 03 7月, 2013 1 次提交
    • B
      cxgb3: Missing rtnl lock in error recovery · 7cc47d13
      Benjamin Herrenschmidt 提交于
      When exercising error injection on IBM pseries machine, I hit the
      following warning:
      
      [  251.450043] RTAS: event: 89, Type: Platform Error, Severity: 2
      [  253.549822] cxgb3 0006:01:00.0: enabling device (0140 -> 0142)
      [  253.713560] cxgb3 0006:01:00.0: adapter recovering, PEX ERR 0x100
      [  254.895437] RTNL: assertion failed at net/core/dev.c (2031)
      [  254.895467] CPU: 6 PID: 5449 Comm: eehd Tainted: G        W    3.10.0-rc7-00157-gea461abf #19
      [  254.895474] Call Trace:
      [  254.895483] [c000000fac56f7d0] [c000000000014dcc] .show_stack+0x7c/0x1f0 (unreliable)
      [  254.895493] [c000000fac56f8a0] [c0000000007ba318] .dump_stack+0x28/0x3c
      [  254.895500] [c000000fac56f910] [c0000000006c0384] .netif_set_real_num_tx_queues+0x224/0x230
      [  254.895515] [c000000fac56f9b0] [d00000000ef35510] .cxgb_open+0x80/0x3f0 [cxgb3]
      [  254.895525] [c000000fac56fa50] [d00000000ef35914] .t3_resume_ports+0x94/0x100 [cxgb3]
      [  254.895533] [c000000fac56fae0] [c00000000005fc8c] .eeh_report_resume+0x8c/0xd0
      [  254.895539] [c000000fac56fb60] [c00000000005e9fc] .eeh_pe_dev_traverse+0x9c/0x190
      [  254.895545] [c000000fac56fc10] [c000000000060000] .eeh_handle_event+0x110/0x330
      [  254.895551] [c000000fac56fca0] [c000000000060350] .eeh_event_handler+0x130/0x1a0
      [  254.895558] [c000000fac56fd30] [c0000000000ad758] .kthread+0xe8/0xf0
      [  254.895566] [c000000fac56fe30] [c00000000000a05c] .ret_from_kernel_thread+0x5c/0x80
      
      It appears that t3_resume_ports() is called with the rtnl_lock held from
      the fatal error task but not from the PCI error callbacks. This fixes it.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cc47d13
  2. 02 7月, 2013 26 次提交
  3. 30 6月, 2013 1 次提交
  4. 29 6月, 2013 8 次提交
  5. 28 6月, 2013 4 次提交
    • N
      bonding: when cloning a MAC use NET_ADDR_STOLEN · ae0d6750
      nikolay@redhat.com 提交于
      A simple semantic change, when a slave's MAC is cloned by the bond
      master then set addr_assign_type to NET_ADDR_STOLEN instead of
      NET_ADDR_SET. Also use bond_set_dev_addr() in BOND_FOM_ACTIVE mode
      to change the bond's MAC address because the assign_type has to be
      set properly.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae0d6750
    • N
      bonding: remove unnecessary dev_addr_from_first member · 97a1e639
      nikolay@redhat.com 提交于
      In struct bonding there's a member called dev_addr_from_first which is
      used to denote when the bond dev should clone the first slave's MAC
      address but since we have netdev's addr_assign_type variable that is not
      necessary. We clone the first slave's MAC each time we have a random MAC
      set to the bond device. This has the nice side-effect of also fixing an
      inconsistency - when the MAC address of the bond dev is set after its
      creation, but prior to having slaves, it's not kept and the first slave's
      MAC is cloned. The only way to keep the MAC was to create the bond device
      with the MAC address set (e.g. through ip link). In all cases if the
      bond device is left without any slaves - its MAC gets reset to a random
      one as before.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97a1e639
    • N
      bonding: remove unnecessary setup_by_slave member · 8d2ada77
      nikolay@redhat.com 提交于
      We have a member called setup_by_slave in struct bonding to denote if the
      bond dev has different type than ARPHRD_ETHER, but that is already denoted
      in bond's netdev type variable if it was setup by the slave, so use that
      instead of the member.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d2ada77
    • J
      ath10k: minimally handle new channel width enumeration values · 0f817ed5
      John W. Linville 提交于
        CC      drivers/net/wireless/ath/ath10k/mac.o
      drivers/net/wireless/ath/ath10k/mac.c: In function ‘chan_to_phymode’:
      drivers/net/wireless/ath/ath10k/mac.c:229:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_5’ not handled in switch [-Wswitch]
      drivers/net/wireless/ath/ath10k/mac.c:229:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_10’ not handled in switch [-Wswitch]
      drivers/net/wireless/ath/ath10k/mac.c:247:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_5’ not handled in switch [-Wswitch]
      drivers/net/wireless/ath/ath10k/mac.c:247:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_10’ not handled in switch [-Wswitch]
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0f817ed5