1. 09 Jul, 2012 3 commits
    • Eliad Peller's avatar
      mac80211: destroy assoc_data correctly if assoc fails · 10a9109f
      Eliad Peller authored
      
      
      If association failed due to internal error (e.g. no
      supported rates IE), we call ieee80211_destroy_assoc_data()
      with assoc=true, while we actually reject the association.
      
      This results in the BSSID not being zeroed out.
      
      After passing assoc=false, we no longer have to call
      sta_info_destroy_addr() explicitly. While on it, move
      the "associated" message after the assoc_success check.
      
      Cc: stable@vger.kernel.org [3.4+]
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      10a9109f
    • Sasha Levin's avatar
      NFC: Prevent NULL deref when getting socket name · 147f20e3
      Sasha Levin authored
      
      
      llcp_sock_getname can be called without a device attached to the nfc_llcp_sock.
      
      This would lead to the following BUG:
      
      [  362.341807] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [  362.341815] IP: [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
      [  362.341818] PGD 31b35067 PUD 30631067 PMD 0
      [  362.341821] Oops: 0000 [#627] PREEMPT SMP DEBUG_PAGEALLOC
      [  362.341826] CPU 3
      [  362.341827] Pid: 7816, comm: trinity-child55 Tainted: G      D W    3.5.0-rc4-next-20120628-sasha-00005-g9f23eb7 #479
      [  362.341831] RIP: 0010:[<ffffffff836258e5>]  [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
      [  362.341832] RSP: 0018:ffff8800304fde88  EFLAGS: 00010286
      [  362.341834] RAX: 0000000000000000 RBX: ffff880033cb8000 RCX: 0000000000000001
      [  362.341835] RDX: ffff8800304fdec4 RSI: ffff8800304fdec8 RDI: ffff8800304fdeda
      [  362.341836] RBP: ffff8800304fdea8 R08: 7ebcebcb772b7ffb R09: 5fbfcb9c35bdfd53
      [  362.341838] R10: 4220020c54326244 R11: 0000000000000246 R12: ffff8800304fdec8
      [  362.341839] R13: ffff8800304fdec4 R14: ffff8800304fdec8 R15: 0000000000000044
      [  362.341841] FS:  00007effa376e700(0000) GS:ffff880035a00000(0000) knlGS:0000000000000000
      [  362.341843] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  362.341844] CR2: 0000000000000000 CR3: 0000000030438000 CR4: 00000000000406e0
      [  362.341851] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  362.341856] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  362.341858] Process trinity-child55 (pid: 7816, threadinfo ffff8800304fc000, task ffff880031270000)
      [  362.341858] Stack:
      [  362.341862]  ffff8800304fdea8 ffff880035156780 0000000000000000 0000000000001000
      [  362.341865]  ffff8800304fdf78 ffffffff83183b40 00000000304fdec8 0000006000000000
      [  362.341868]  ffff8800304f0027 ffffffff83729649 ffff8800304fdee8 ffff8800304fdf48
      [  362.341869] Call Trace:
      [  362.341874]  [<ffffffff83183b40>] sys_getpeername+0xa0/0x110
      [  362.341877]  [<ffffffff83729649>] ? _raw_spin_unlock_irq+0x59/0x80
      [  362.341882]  [<ffffffff810f342b>] ? do_setitimer+0x23b/0x290
      [  362.341886]  [<ffffffff81985ede>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [  362.341889]  [<ffffffff8372a539>] system_call_fastpath+0x16/0x1b
      [  362.341921] Code: 84 00 00 00 00 00 b8 b3 ff ff ff 48 85 db 74 54 66 41 c7 04 24 27 00 49 8d 7c 24 12 41 c7 45 00 60 00 00 00 48 8b 83 28 05 00 00 <8b> 00 41 89 44 24 04 0f b6 83 41 05 00 00 41 88 44 24 10 0f b6
      [  362.341924] RIP  [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
      [  362.341925]  RSP <ffff8800304fde88>
      [  362.341926] CR2: 0000000000000000
      [  362.341928] ---[ end trace 6d450e935ee18bf3 ]---
      
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      147f20e3
    • Thomas Huehn's avatar
      mac80211: correct size the argument to kzalloc in minstrel_ht · 472dd35c
      Thomas Huehn authored
      
      
      msp has type struct minstrel_ht_sta_priv not struct minstrel_ht_sta.
      
      (This incorporates the fixup originally posted as "mac80211: fix kzalloc
      memory corruption introduced in minstrel_ht". -- JWL)
      
      Reported-by: default avatarFengguang Wu <wfg@linux.intel.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarThomas Huehn <thomas@net.t-labs.tu-berlin.de>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      472dd35c
  2. 27 Jun, 2012 5 commits
  3. 26 Jun, 2012 1 commit
  4. 25 Jun, 2012 5 commits
    • Eric Dumazet's avatar
      NFC: Return from rawsock_release when sk is NULL · 03e934f6
      Eric Dumazet authored
      
      
      Sasha Levin reported following panic :
      
      [ 2136.383310] BUG: unable to handle kernel NULL pointer dereference at
      00000000000003b0
      [ 2136.384022] IP: [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
      [ 2136.384022] PGD 131c4067 PUD 11c0c067 PMD 0
      [ 2136.388106] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [ 2136.388106] CPU 1
      [ 2136.388106] Pid: 24855, comm: trinity-child1 Tainted: G        W
      3.5.0-rc2-sasha-00015-g7b268f7 #374
      [ 2136.388106] RIP: 0010:[<ffffffff8114e400>]  [<ffffffff8114e400>]
      __lock_acquire+0xc0/0x4b0
      [ 2136.388106] RSP: 0018:ffff8800130b3ca8  EFLAGS: 00010046
      [ 2136.388106] RAX: 0000000000000086 RBX: ffff88001186b000 RCX:
      0000000000000000
      [ 2136.388106] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
      0000000000000000
      [ 2136.388106] RBP: ffff8800130b3d08 R08: 0000000000000001 R09:
      0000000000000000
      [ 2136.388106] R10: 0000000000000000 R11: 0000000000000001 R12:
      0000000000000002
      [ 2136.388106] R13: 00000000000003b0 R14: 0000000000000000 R15:
      0000000000000000
      [ 2136.388106] FS:  00007fa5b1bd4700(0000) GS:ffff88001b800000(0000)
      knlGS:0000000000000000
      [ 2136.388106] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2136.388106] CR2: 00000000000003b0 CR3: 0000000011d1f000 CR4:
      00000000000406e0
      [ 2136.388106] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
      0000000000000000
      [ 2136.388106] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
      0000000000000400
      [ 2136.388106] Process trinity-child1 (pid: 24855, threadinfo
      ffff8800130b2000, task ffff88001186b000)
      [ 2136.388106] Stack:
      [ 2136.388106]  ffff8800130b3cd8 ffffffff81121785 ffffffff81236774
      000080d000000001
      [ 2136.388106]  ffff88001b9d6c00 00000000001d6c00 ffffffff130b3d08
      ffff88001186b000
      [ 2136.388106]  0000000000000000 0000000000000002 0000000000000000
      0000000000000000
      [ 2136.388106] Call Trace:
      [ 2136.388106]  [<ffffffff81121785>] ? sched_clock_local+0x25/0x90
      [ 2136.388106]  [<ffffffff81236774>] ? get_empty_filp+0x74/0x220
      [ 2136.388106]  [<ffffffff8114e97a>] lock_acquire+0x18a/0x1e0
      [ 2136.388106]  [<ffffffff836b37df>] ? rawsock_release+0x4f/0xa0
      [ 2136.388106]  [<ffffffff837c0ef0>] _raw_write_lock_bh+0x40/0x80
      [ 2136.388106]  [<ffffffff836b37df>] ? rawsock_release+0x4f/0xa0
      [ 2136.388106]  [<ffffffff836b37df>] rawsock_release+0x4f/0xa0
      [ 2136.388106]  [<ffffffff8321cfe8>] sock_release+0x18/0x70
      [ 2136.388106]  [<ffffffff8321d069>] sock_close+0x29/0x30
      [ 2136.388106]  [<ffffffff81236bca>] __fput+0x11a/0x2c0
      [ 2136.388106]  [<ffffffff81236d85>] fput+0x15/0x20
      [ 2136.388106]  [<ffffffff8321de34>] sys_accept4+0x1b4/0x200
      [ 2136.388106]  [<ffffffff837c165c>] ? _raw_spin_unlock_irq+0x4c/0x80
      [ 2136.388106]  [<ffffffff837c1669>] ? _raw_spin_unlock_irq+0x59/0x80
      [ 2136.388106]  [<ffffffff837c2565>] ? sysret_check+0x22/0x5d
      [ 2136.388106]  [<ffffffff8321de8b>] sys_accept+0xb/0x10
      [ 2136.388106]  [<ffffffff837c2539>] system_call_fastpath+0x16/0x1b
      [ 2136.388106] Code: ec 04 00 0f 85 ea 03 00 00 be d5 0b 00 00 48 c7 c7
      8a c1 40 84 e8 b1 a5 f8 ff 31 c0 e9 d4 03 00 00 66 2e 0f 1f 84 00 00 00
      00 00 <49> 81 7d 00 60 73 5e 85 b8 01 00 00 00 44 0f 44 e0 83 fe 01 77
      [ 2136.388106] RIP  [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
      [ 2136.388106]  RSP <ffff8800130b3ca8>
      [ 2136.388106] CR2: 00000000000003b0
      [ 2136.388106] ---[ end trace 6d450e935ee18982 ]---
      [ 2136.388106] Kernel panic - not syncing: Fatal exception in interrupt
      
      rawsock_release() should test if sock->sk is NULL before calling
      sock_orphan()/sock_put()
      
      Reported-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Tested-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      03e934f6
    • Johannes Berg's avatar
      iwlwifi: fix activating inactive stations · eac9ac6d
      Johannes Berg authored
      
      
      When authentication/association timed out, the driver would
      complain bitterly, printing the message
      ACTIVATE a non DRIVER active station id ... addr ...
      
      The cause turns out to be that when the AP station is added
      but we don't associate, the IWL_STA_UCODE_INPROGRESS is set
      but never cleared. This then causes iwl_restore_stations()
      to attempt to resend it because it uses the flag internally
      and uploads even if it didn't set it itself.
      
      To fix this issue and not upload the station again when it
      has already been removed by mac80211, clear the flag after
      adding it in case we add it only for association.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      eac9ac6d
    • Randy Dunlap's avatar
      wlcore: drop INET dependency · ff0b8046
      Randy Dunlap authored
      Mainline build reports:
      
      warning: (WL12XX) selects WLCORE which has unmet direct dependencies (NETDEVICES && WLAN && WL_TI && GENERIC_HARDIRQS && MAC80211 && INET)
      
      The INET dependency was added in commit
      3c6af5b5
      
      :
          wl1271_main.c:(.text+0x271052): undefined reference to `unregister_inetaddr_
      notifier'
          wl1271_main.c:(.text+0x2714d7): undefined reference to `register_inetaddr_no
      tifier'
      
          Driver is doing some filtering based on IP addresses...
      
      but this driver no longer has that code and it builds fine even when
      CONFIG_INET is not enabled, so drop that dependency and eliminate the
      kconfig warning message.
      
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Cc: Luciano Coelho <luciano.coelho@nokia.com>
      Cc: John W. Linville <linville@tuxdriver.com>
      Acked-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ff0b8046
    • Felix Fietkau's avatar
      ath9k: fix dynamic WEP related regression · bed3d9c0
      Felix Fietkau authored
      commit 7a532fe7
      
      
      ath9k_hw: fix interpretation of the rx KeyMiss flag
      
      This commit used the rx key miss indication to detect packets that were
      passed from the hardware without being decrypted, however it seems that
      this bit is not only undefined in the static WEP case, but also for
      dynamically allocated WEP keys. This caused a regression when using
      WEP-LEAP.
      
      This patch fixes the regression by keeping track of which key indexes
      refer to CCMP keys and only using the key miss indication for those.
      
      Reported-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bed3d9c0
    • Dan Rosenberg's avatar
      NFC: Prevent multiple buffer overflows in NCI · 67de956f
      Dan Rosenberg authored
      
      
      Fix multiple remotely-exploitable stack-based buffer overflows due to
      the NCI code pulling length fields directly from incoming frames and
      copying too much data into statically-sized arrays.
      
      Signed-off-by: default avatarDan Rosenberg <dan.j.rosenberg@gmail.com>
      Cc: stable@kernel.org
      Cc: security@kernel.org
      Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
      Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Acked-by: default avatarIlan Elias <ilane@ti.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      67de956f
  5. 22 Jun, 2012 5 commits
  6. 21 Jun, 2012 1 commit
  7. 20 Jun, 2012 6 commits
  8. 19 Jun, 2012 7 commits
  9. 18 Jun, 2012 1 commit
  10. 14 Jun, 2012 1 commit
  11. 13 Jun, 2012 5 commits
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix softlockup in AR9485 · bcb7ad7b
      Mohammed Shafi Shajakhan authored
      steps to recreate:
      load latest ath9k driver with AR9485
      stop the network-manager and wpa_supplicant
      bring the interface up
      
      	Call Trace:
      	[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
      	[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
      	[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
      	[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
      	[<ffffffff810744fe>] process_one_work+0x11e/0x470
      	[<ffffffff8107530f>] worker_thread+0x15f/0x360
      	[<ffffffff810751b0>] ? manage_workers+0x230/0x230
      	[<ffffffff81079af3>] kthread+0x93/0xa0
      	[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
      	[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
      	[<ffffffff815fd3a0>] ? gs_change+0x13/0x13
      
      ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
      associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
      is needed to recover from some rare beacon stuck during stress testing.
      Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
      always seem to have zero even though we had configured PLL3(0x16188) to
      query about PLL's locking status. When we keep on polling infinitely PLL4's
      8th bit(ie check for PLL locking measurements is done), machine hangs
      due to softlockup.
      
      fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142
      
      
      
      Reported-by: default avatarRolf Offermanns <rolf.offermanns@gmx.net>
      Cc: stable@vger.kernel.org [3.0+]
      Tested-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bcb7ad7b
    • John W. Linville's avatar
    • David Spinadel's avatar
      mac80211: stop polling in disassociation · 79543d8e
      David Spinadel authored
      
      
      Stop connection monitor poll during disassociation.
      This clears the polling flags and if a scan was
      deferred it will be run.
      
      Without this fix, if a scan was deferred due to
      connection monitoring while disassociation happens,
      this scan blocks further scan requests until interface
      down/up which causes problems connecting to another AP.
      
      Signed-off-by: default avatarDavid Spinadel <david.spinadel@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      79543d8e
    • Eliad Peller's avatar
      mac80211: check sdata_running on ieee80211_set_bitrate_mask · 554a43d5
      Eliad Peller authored
      
      
      Otherwise, we might call the driver callback before
      the interface was uploaded.
      
      Solves the following warning:
      WARNING: at net/mac80211/driver-ops.h:12 ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]()
      wlan0:  Failed check-sdata-in-driver check, flags: 0x0
      Modules linked in: wlcore_sdio wl12xx wl18xx wlcore mac80211 cfg80211 [last unloaded: cfg80211]
      [<c001b964>] (unwind_backtrace+0x0/0x12c) from [<c0495550>] (dump_stack+0x20/0x24)
      [<c0495550>] (dump_stack+0x20/0x24) from [<c003ee28>] (warn_slowpath_common+0x5c/0x74)
      [<c003ee28>] (warn_slowpath_common+0x5c/0x74) from [<c003eefc>] (warn_slowpath_fmt+0x40/0x48)
      [<c003eefc>] (warn_slowpath_fmt+0x40/0x48) from [<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211])
      [<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]) from [<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211])
      [<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211]) from [<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8)
      [<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8) from [<c03e9164>] (netlink_rcv_skb+0x5c/0xc0)
      [<c03e9164>] (netlink_rcv_skb+0x5c/0xc0) from [<c03e9ce0>] (genl_rcv+0x28/0x34)
      [<c03e9ce0>] (genl_rcv+0x28/0x34) from [<c03e8e74>] (netlink_unicast+0x158/0x234)
      [<c03e8e74>] (netlink_unicast+0x158/0x234) from [<c03e93e0>] (netlink_sendmsg+0x218/0x298)
      [<c03e93e0>] (netlink_sendmsg+0x218/0x298) from [<c03b4e5c>] (sock_sendmsg+0xa4/0xc0)
      [<c03b4e5c>] (sock_sendmsg+0xa4/0xc0) from [<c03b5af4>] (__sys_sendmsg+0x1d8/0x254)
      [<c03b5af4>] (__sys_sendmsg+0x1d8/0x254) from [<c03b5ca8>] (sys_sendmsg+0x4c/0x70)
      [<c03b5ca8>] (sys_sendmsg+0x4c/0x70) from [<c0013980>] (ret_fast_syscall+0x0/0x3c)
      
      Note that calling the driver can also result
      in undefined behaviour since it doesn't have
      to deal with calls while down.
      
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      [removed timestamps, added note - Johannes]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      554a43d5
    • Eliad Peller's avatar
      cfg80211: fix potential deadlock in regulatory · fe20b39e
      Eliad Peller authored
      
      
      reg_timeout_work() calls restore_regulatory_settings() which
      takes cfg80211_mutex.
      
      reg_set_request_processed() already holds cfg80211_mutex
      before calling cancel_delayed_work_sync(reg_timeout),
      so it might deadlock.
      
      Call the async cancel_delayed_work instead, in order
      to avoid the potential deadlock.
      
      This is the relevant lockdep warning:
      
      cfg80211: Calling CRDA for country: XX
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.4.0-rc5-wl+ #26 Not tainted
      -------------------------------------------------------
      kworker/0:2/1391 is trying to acquire lock:
       (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
      
      but task is already holding lock:
       ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 ((reg_timeout).work){+.+...}:
             [<c008fd44>] validate_chain+0xb94/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c005b600>] wait_on_work+0x4c/0x154
             [<c005c000>] __cancel_work_timer+0xd4/0x11c
             [<c005c064>] cancel_delayed_work_sync+0x1c/0x20
             [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
             [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
             [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
             [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
             [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
             [<c03c7584>] genl_rcv+0x28/0x34
             [<c03c6720>] netlink_unicast+0x15c/0x228
             [<c03c6c7c>] netlink_sendmsg+0x218/0x298
             [<c03933c8>] sock_sendmsg+0xa4/0xc0
             [<c039406c>] __sys_sendmsg+0x1e4/0x268
             [<c0394228>] sys_sendmsg+0x4c/0x70
             [<c0013840>] ret_fast_syscall+0x0/0x3c
      
      -> #1 (reg_mutex){+.+.+.}:
             [<c008fd44>] validate_chain+0xb94/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c04734dc>] mutex_lock_nested+0x48/0x320
             [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
             [<c0059f44>] process_one_work+0x2a0/0x480
             [<c005a4b4>] worker_thread+0x1bc/0x2bc
             [<c0061148>] kthread+0x98/0xa4
             [<c0014af4>] kernel_thread_exit+0x0/0x8
      
      -> #0 (cfg80211_mutex){+.+.+.}:
             [<c008ed58>] print_circular_bug+0x68/0x2cc
             [<c008fb28>] validate_chain+0x978/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c04734dc>] mutex_lock_nested+0x48/0x320
             [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
             [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
             [<c0059f44>] process_one_work+0x2a0/0x480
             [<c005a4b4>] worker_thread+0x1bc/0x2bc
             [<c0061148>] kthread+0x98/0xa4
             [<c0014af4>] kernel_thread_exit+0x0/0x8
      
      other info that might help us debug this:
      
      Chain exists of:
        cfg80211_mutex --> reg_mutex --> (reg_timeout).work
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock((reg_timeout).work);
                                     lock(reg_mutex);
                                     lock((reg_timeout).work);
        lock(cfg80211_mutex);
      
       *** DEADLOCK ***
      
      2 locks held by kworker/0:2/1391:
       #0:  (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
       #1:  ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
      
      stack backtrace:
      [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
      [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
      [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
      [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
      [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
      [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
      [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
      [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
      [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
      [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
      [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
      [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
      cfg80211: Calling CRDA to update world regulatory domain
      cfg80211: World regulatory domain updated:
      cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
      cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe20b39e