1. 24 8月, 2016 1 次提交
    • M
      brcmfmac: Check rtnl_lock is locked when removing interface · 15dacf88
      mhiramat@kernel.org 提交于
      Check rtnl_lock is locked in brcmf_p2p_ifp_removed() by passing
      rtnl_locked flag. Actually the caller brcmf_del_if() checks whether
      the rtnl_lock is locked, but doesn't pass it to brcmf_p2p_ifp_removed().
      
      Without this fix, wpa_supplicant goes softlockup with rtnl_lock
      holding (this means all other process using netlink are locked up too)
      
      e.g.
      [ 4495.876627] INFO: task wpa_supplicant:7307 blocked for more than 10 seconds.
      [ 4495.876632]       Tainted: G        W       4.8.0-rc1+ #8
      [ 4495.876635] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 4495.876638] wpa_supplicant  D ffff974c647b39a0     0  7307      1 0x00000000
      [ 4495.876644]  ffff974c647b39a0 0000000000000000 ffff974c00000000 ffff974c7dc59c58
      [ 4495.876651]  ffff974c6b7417c0 ffff974c645017c0 ffff974c647b4000 ffffffff86f16c08
      [ 4495.876657]  ffff974c645017c0 0000000000000246 00000000ffffffff ffff974c647b39b8
      [ 4495.876664] Call Trace:
      [ 4495.876671]  [<ffffffff868aeccc>] schedule+0x3c/0x90
      [ 4495.876676]  [<ffffffff868af065>] schedule_preempt_disabled+0x15/0x20
      [ 4495.876682]  [<ffffffff868b0996>] mutex_lock_nested+0x176/0x3b0
      [ 4495.876686]  [<ffffffff867a2067>] ? rtnl_lock+0x17/0x20
      [ 4495.876690]  [<ffffffff867a2067>] rtnl_lock+0x17/0x20
      [ 4495.876720]  [<ffffffffc0ae9a5d>] brcmf_p2p_ifp_removed+0x4d/0x70 [brcmfmac]
      [ 4495.876741]  [<ffffffffc0aebde6>] brcmf_remove_interface+0x196/0x1b0 [brcmfmac]
      [ 4495.876760]  [<ffffffffc0ae9901>] brcmf_p2p_del_vif+0x111/0x220 [brcmfmac]
      [ 4495.876777]  [<ffffffffc0adefab>] brcmf_cfg80211_del_iface+0x21b/0x270 [brcmfmac]
      [ 4495.876820]  [<ffffffffc097b39e>] nl80211_del_interface+0xfe/0x3a0 [cfg80211]
      [ 4495.876825]  [<ffffffff867ca335>] genl_family_rcv_msg+0x1b5/0x370
      [ 4495.876832]  [<ffffffff860e5d8d>] ? trace_hardirqs_on+0xd/0x10
      [ 4495.876836]  [<ffffffff867ca56d>] genl_rcv_msg+0x7d/0xb0
      [ 4495.876839]  [<ffffffff867ca4f0>] ? genl_family_rcv_msg+0x370/0x370
      [ 4495.876846]  [<ffffffff867c9a47>] netlink_rcv_skb+0x97/0xb0
      [ 4495.876849]  [<ffffffff867ca168>] genl_rcv+0x28/0x40
      [ 4495.876854]  [<ffffffff867c93c3>] netlink_unicast+0x1d3/0x2f0
      [ 4495.876860]  [<ffffffff867c933b>] ? netlink_unicast+0x14b/0x2f0
      [ 4495.876866]  [<ffffffff867c97cb>] netlink_sendmsg+0x2eb/0x3a0
      [ 4495.876870]  [<ffffffff8676dad8>] sock_sendmsg+0x38/0x50
      [ 4495.876874]  [<ffffffff8676e4df>] ___sys_sendmsg+0x27f/0x290
      [ 4495.876882]  [<ffffffff8628b935>] ? mntput_no_expire+0x5/0x3f0
      [ 4495.876888]  [<ffffffff8628b9be>] ? mntput_no_expire+0x8e/0x3f0
      [ 4495.876894]  [<ffffffff8628b935>] ? mntput_no_expire+0x5/0x3f0
      [ 4495.876899]  [<ffffffff8628bd44>] ? mntput+0x24/0x40
      [ 4495.876904]  [<ffffffff86267830>] ? __fput+0x190/0x200
      [ 4495.876909]  [<ffffffff8676f125>] __sys_sendmsg+0x45/0x80
      [ 4495.876914]  [<ffffffff8676f172>] SyS_sendmsg+0x12/0x20
      [ 4495.876918]  [<ffffffff868b5680>] entry_SYSCALL_64_fastpath+0x23/0xc1
      [ 4495.876924]  [<ffffffff860e2b8f>] ? trace_hardirqs_off_caller+0x1f/0xc0
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: NRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      15dacf88
  2. 08 7月, 2016 1 次提交
    • R
      brcmfmac: delete interface directly in code that sent fw request · a63b0987
      Rafał Miłecki 提交于
      So far when receiving event about in-firmware-interface removal our
      event worker was notifying listener and afterwards it was removing Linux
      interface.
      
      First of all it was resulting in slightly unexpected order. The listener
      (del_virtual_intf callback) was (usually) returning with success before
      we even called unregister_netdev(ice).
      
      Please note this couldn't be simply fixed by changing order of calls in
      brcmf_fweh_handle_if_event as unregistering interface earlier could free
      struct brcmf_if.
      
      Another problem of current implementation are possible lockups. Focus on
      the time slot between calling event handler and removing Linux
      interface. During that time original caller may leave (unlocking rtnl
      semaphore) *and* another call to the same code may be done (locking it
      again). If that happens our event handler will stuck at removing Linux
      interface, it won't handle another event and will block process holding
      rtnl lock.
      
      This can be simply solved by unregistering interface in a proper
      callback, right after receiving confirmation event from firmware. This
      only required modifying worker to don't unregister on its own if there
      is someone waiting for the event.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      a63b0987
  3. 30 6月, 2016 1 次提交
  4. 29 6月, 2016 1 次提交
  5. 16 6月, 2016 2 次提交
  6. 14 6月, 2016 1 次提交
    • R
      brcmutil: add field storing control channel to the struct brcmu_chan · 4712d88a
      Rafał Miłecki 提交于
      Our d11 code supports encoding/decoding channel info into/from chanspec
      format used by firmware. Current implementation is quite misleading
      because of the way "chnum" field is used.
      When encoding channel info, "chnum" has to be filled by a caller with
      *center* channel number. However when decoding chanspec the same field
      is filled with a *control* channel number.
      
      1) This can be confusing. It's expected for information to be the same
         after encoding and decoding.
      2) It doesn't allow accessing all info when decoding. Some functions may
         need to know both channel numbers, e.g. cfg80211 callback getting
         current channel.
      Solve this by adding a separated field for control channel.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Reviewed-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      4712d88a
  7. 14 4月, 2016 1 次提交
  8. 12 4月, 2016 1 次提交
  9. 07 3月, 2016 2 次提交
  10. 08 1月, 2016 1 次提交
  11. 30 11月, 2015 2 次提交
  12. 26 11月, 2015 1 次提交
  13. 18 11月, 2015 1 次提交
  14. 21 10月, 2015 1 次提交
  15. 29 9月, 2015 6 次提交
  16. 16 6月, 2015 1 次提交
  17. 15 6月, 2015 3 次提交
  18. 30 3月, 2015 1 次提交
    • T
      cfg80211: pass name_assign_type to rdev_add_virtual_intf() · 6bab2e19
      Tom Gundersen 提交于
      This will expose in /sys whether the ifname of a device is set by
      userspace or generated by the kernel. The latter kind (wlanX, etc)
      is not deterministic, so userspace needs to rename these devices
      to names that are guaranteed to stay the same between reboots. The
      former, however should never be renamed, so userspace needs to be
      able to reliably tell the difference.
      
      Similar functionality was introduced for the rtnetlink core in
      commit 5517750f ("net: rtnetlink - make create_link take name_assign_type")
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
      Cc: Hante Meuleman <meuleman@broadcom.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      [reformat changelog to fit 72 cols]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6bab2e19
  19. 04 3月, 2015 1 次提交
  20. 31 10月, 2014 3 次提交
  21. 01 10月, 2014 1 次提交
  22. 26 8月, 2014 1 次提交
  23. 21 7月, 2014 1 次提交
  24. 26 6月, 2014 1 次提交
  25. 18 3月, 2014 1 次提交
  26. 07 1月, 2014 2 次提交
  27. 27 12月, 2013 1 次提交