Linux-Wireless Archive on lore.kernel.org
 help / color / Atom feed
From: dave@bewaar.me
To: Amitkumar Karwar <amitkarwar@gmail.com>,
	anapathi Bhat <ganapathi017@gmail.com>,
	Sharvari Harisangam <sharvari.harisangam@nxp.com>,
	Xinming Hu <huxinming820@gmail.com>,
	Kalle Valo <kvalo@codeaurora.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Johannes Berg <johannes.berg@intel.com>
Subject: [BUG] recursive lock in mwifiex_uninit_sw
Date: Fri, 14 May 2021 14:45:10 +0200
Message-ID: <ab4d00ce52f32bd8e45ad0448a44737e@bewaar.me> (raw)

A firmware crash of the Marvell 88W8897, which are spurious on Microsoft
Surface devices, will unload/reset the device. However this can also 
fail
in more recent kernels, which can cause more problems since the driver
does not unload. This causes programs trying to reach the network or
networking devices to hang which in turn causes a reboot/poweroff to 
hang.

This can happen on the following fedora rawhide kernels:
- 5.12.0-0.rc8.20210423git7af08140979a.193.fc35.x86_64 [1]
- 5.13.0-0.rc1.20210512git88b06399c9c7.15.fc35.x86_64 [2]

The latter seems to be more consistent in triggering this behaviour
(and crashing the firmware). If someone can give me some pointers
I would gladly help and debug this.

I know there is a set of patches for surface devices which address
these firmware crashes [3], however they have not made it upstream
yet and are not in the before mentioned kernels with this issue.

Regards,
Dave

[1]: 
https://gitlab.com/cki-project/kernel-ark/-/commit/bfe9c6281b1e9a08ad94ff76629279326a8483c1
[2]: 
https://gitlab.com/cki-project/kernel-ark/-/commit/b996c16ff61d147d9a02c74d600b4c576aea9f3a
[3]: 
https://github.com/linux-surface/linux-surface/blob/master/patches/5.12/0002-mwifiex.patch

[  440.345579] ============================================
[  440.345583] WARNING: possible recursive locking detected
[  440.345587] 5.13.0-0.rc1.20210512git88b06399c9c7.15.fc35.x86_64 #1 
Not tainted
[  440.345592] --------------------------------------------
[  440.345595] kworker/0:2/121 is trying to acquire lock:
[  440.345599] ffff9bbbc6792670 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: 
cfg80211_netdev_notifier_call+0xf8/0x5c0 [cfg80211]
[  440.345734]
                but task is already holding lock:
[  440.345737] ffff9bbbc6792670 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: 
mwifiex_uninit_sw+0x151/0x1f0 [mwifiex]
[  440.345783]
                other info that might help us debug this:
[  440.345786]  Possible unsafe locking scenario:

[  440.345788]        CPU0
[  440.345790]        ----
[  440.345792]   lock(&rdev->wiphy.mtx);
[  440.345797]   lock(&rdev->wiphy.mtx);
[  440.345801]
                 *** DEADLOCK ***

[  440.345804]  May be due to missing lock nesting notation

[  440.345806] 5 locks held by kworker/0:2/121:
[  440.345810]  #0: ffff9bbb80055148 
((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x21a/0x5e0
[  440.345825]  #1: ffffba12814b3e70 
((work_completion)(&card->work)){+.+.}-{0:0}, at: 
process_one_work+0x21a/0x5e0
[  440.345837]  #2: ffff9bbb82263258 (&dev->mutex){....}-{3:3}, at: 
pci_try_reset_function+0x3d/0x90
[  440.345852]  #3: ffffffffa11e7f90 (rtnl_mutex){+.+.}-{3:3}, at: 
mwifiex_uninit_sw+0x146/0x1f0 [mwifiex]
[  440.345879]  #4: ffff9bbbc6792670 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: 
mwifiex_uninit_sw+0x151/0x1f0 [mwifiex]
[  440.345906]
                stack backtrace:
[  440.345909] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 
5.13.0-0.rc1.20210512git88b06399c9c7.15.fc35.x86_64 #1
[  440.345915] Hardware name: Microsoft Corporation Surface Pro/Surface 
Pro, BIOS 235.3440.768 11.16.2020
[  440.345919] Workqueue: events mwifiex_pcie_work [mwifiex_pcie]
[  440.345928] Call Trace:
[  440.345935]  dump_stack+0x7f/0xa1
[  440.345943]  __lock_acquire.cold+0x17d/0x2bf
[  440.345953]  ? lock_is_held_type+0xa7/0x120
[  440.345961]  lock_acquire+0xc4/0x3a0
[  440.345967]  ? cfg80211_netdev_notifier_call+0xf8/0x5c0 [cfg80211]
[  440.346062]  ? __bfs+0xf5/0x230
[  440.346069]  ? lock_is_held_type+0xa7/0x120
[  440.346077]  __mutex_lock+0x91/0x830
[  440.346082]  ? cfg80211_netdev_notifier_call+0xf8/0x5c0 [cfg80211]
[  440.346175]  ? __bfs+0xf5/0x230
[  440.346181]  ? cfg80211_netdev_notifier_call+0xf8/0x5c0 [cfg80211]
[  440.346270]  ? check_path.constprop.0+0x24/0x50
[  440.346278]  ? check_noncircular+0x70/0x100
[  440.346286]  ? cfg80211_netdev_notifier_call+0xf8/0x5c0 [cfg80211]
[  440.346375]  cfg80211_netdev_notifier_call+0xf8/0x5c0 [cfg80211]
[  440.346471]  ? __lock_acquire+0x3ac/0x1e10
[  440.346481]  ? lock_acquire+0xc4/0x3a0
[  440.346486]  ? lock_is_held_type+0xa7/0x120
[  440.346492]  ? find_held_lock+0x32/0x90
[  440.346499]  ? sched_clock_cpu+0xc/0xb0
[  440.346505]  ? lock_is_held_type+0xa7/0x120
[  440.346510]  ? cfg80211_register_netdevice+0x130/0x130 [cfg80211]
[  440.346604]  ? rcu_read_lock_sched_held+0x3f/0x80
[  440.346615]  notifier_call_chain+0x42/0xb0
[  440.346624]  __dev_close_many+0x62/0x100
[  440.346634]  dev_close_many+0x7b/0x110
[  440.346641]  unregister_netdevice_many+0x14b/0x760
[  440.346650]  unregister_netdevice_queue+0xab/0xf0
[  440.346658]  _cfg80211_unregister_wdev+0x170/0x210 [cfg80211]
[  440.346752]  mwifiex_del_virtual_intf+0x178/0x1a0 [mwifiex]
[  440.346778]  mwifiex_uninit_sw+0x1d5/0x1f0 [mwifiex]
[  440.346801]  mwifiex_shutdown_sw+0x5c/0x90 [mwifiex]
[  440.346822]  mwifiex_pcie_reset_prepare+0x4d/0x90 [mwifiex_pcie]
[  440.346829]  pci_dev_save_and_disable+0x29/0x50
[  440.346835]  pci_try_reset_function+0x49/0x90
[  440.346840]  process_one_work+0x2b0/0x5e0
[  440.346849]  worker_thread+0x55/0x3c0
[  440.346854]  ? process_one_work+0x5e0/0x5e0
[  440.346860]  kthread+0x13a/0x150
[  440.346865]  ? __kthread_bind_mask+0x60/0x60
[  440.346871]  ret_from_fork+0x22/0x30

             reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 12:45 dave [this message]
2021-05-14 13:57 ` Maximilian Luz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab4d00ce52f32bd8e45ad0448a44737e@bewaar.me \
    --to=dave@bewaar.me \
    --cc=amitkarwar@gmail.com \
    --cc=davem@davemloft.net \
    --cc=ganapathi017@gmail.com \
    --cc=huxinming820@gmail.com \
    --cc=johannes.berg@intel.com \
    --cc=kuba@kernel.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sharvari.harisangam@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Wireless Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-wireless/0 linux-wireless/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-wireless linux-wireless/ https://lore.kernel.org/linux-wireless \
		linux-wireless@vger.kernel.org
	public-inbox-index linux-wireless

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-wireless


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git