Re: [PATCH 09/13] cfg80211: Save the regulatory domain when setting custom regulatory

From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Luca Coelho <luca@coelho.fi>, johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 09/13] cfg80211: Save the regulatory domain when setting custom regulatory
Date: Wed, 16 Dec 2020 11:20:05 +0100	[thread overview]
Message-ID: <d70a4e97-48e0-a4a4-40c2-77a7557db2ce@samsung.com> (raw)
In-Reply-To: <iwlwifi.20201129172929.290fa5c5568a.Ic5732aa64de6ee97ae3578bd5779fc723ba489d1@changeid>

Hi Luca,

On 29.11.2020 16:30, Luca Coelho wrote:
> From: Ilan Peer <ilan.peer@intel.com>
>
> When custom regulatory was set, only the channels setting was updated, but
> the regulatory domain was not saved. Fix it by saving it.
>
> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

This patch landed recently in linux-next as commit beee24695157 
("cfg80211: Save the regulatory domain when setting custom regulatory"). 
It triggers the following warning on all boards I have, which use 
Broadcom chips. Here is an example from Raspberry Pi4:

cfg80211: Loading compiled-in X.509 certificates for regulatory database
cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip 
BCM4345/6
brcmfmac mmc1:0001:1: Direct firmware load for 
brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2
brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: 
brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip 
BCM4345/6
brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-11), 
device may have limited channels available
brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  1 2015 
07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
Bluetooth: hci0: BCM: chip id 107
Bluetooth: hci0: BCM: features 0x2f
Bluetooth: hci0: BCM4345C0
Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
Bluetooth: hci0: BCM4345C0 'brcm/BCM4345C0.hcd' Patch

=============================
WARNING: suspicious RCU usage
5.10.0-next-20201215+ #9962 Not tainted
-----------------------------
net/wireless/reg.c:144 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by kworker/1:1/32:
  #0: ffff000003405738 ((wq_completion)events){+.+.}-{0:0}, at: 
process_one_work+0x200/0x728
  #1: ffff80001321bdc0 ((work_completion)(&fw_work->work)){+.+.}-{0:0}, 
at: process_one_work+0x200/0x728

stack backtrace:
CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.10.0-next-20201215+ #9962
Hardware name: Raspberry Pi 4 Model B (DT)
Workqueue: events request_firmware_work_func
Call trace:
  dump_backtrace+0x0/0x1d0
  show_stack+0x14/0x60
  dump_stack+0xf4/0x15c
  lockdep_rcu_suspicious+0xd4/0xf8
  get_wiphy_regdom+0x6c/0x70 [cfg80211]
  wiphy_apply_custom_regulatory+0x80/0xc8 [cfg80211]
  brcmf_cfg80211_attach+0xb44/0x1330 [brcmfmac]
  brcmf_attach+0x174/0x4b8 [brcmfmac]
  brcmf_sdio_firmware_callback+0x670/0x7c8 [brcmfmac]
  brcmf_fw_request_done+0x7c/0x100 [brcmfmac]
  request_firmware_work_func+0x4c/0xd8
  process_one_work+0x2a8/0x728
  worker_thread+0x48/0x460
  kthread+0x134/0x160
  ret_from_fork+0x10/0x18

Reverting this patch on top of linux next-20201215 hides this issue.

I compiled kernel for arm64 with defconfig with some additional options 
(I left only those that might be relevant to this issue):

./scripts/config --set-val CMA_SIZE_MBYTES 96 -e PROVE_LOCKING -e 
DEBUG_ATOMIC_SLEEP -e COMPILE_TEST -e PM_DEBUG -e PM_ADVANCED_DEBUG -e 
CONFIG_BRCMFMAC_PCIE

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland