* [PATCH rtw-next] wifi: rtw89: sar: drop assertion from rtw89_sar_set_src()
@ 2025-06-03 15:26 Fedor Pchelkin
2025-06-04 1:28 ` Ping-Ke Shih
0 siblings, 1 reply; 3+ messages in thread
From: Fedor Pchelkin @ 2025-06-03 15:26 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Fedor Pchelkin, Zong-Zhe Yang, linux-wireless, linux-kernel,
lvc-project
rtw89_sar_set_src() may be called at driver early init phase when
applying SAR configuration via ACPI. wiphy lock is not held there.
The only other callsite of the macro triggered by netlink handler
originates from rtw89_ops_set_sar_specs() and does already have the wiphy
lock assertion - and it is actually needed there.
Remove the assertion here in rtw89_sar_set_src() as it may lead to false
alarms now.
Found by Linux Verification Center (linuxtesting.org).
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
---
Urgh, this one wasn't caught as my system doesn't have any SAR available
from ACPI. But it would be falsely triggered, too. If I saw it earlier,
I'd better prepared this as a followup patch in a series though..
drivers/net/wireless/realtek/rtw89/sar.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw89/sar.c b/drivers/net/wireless/realtek/rtw89/sar.c
index 33a4b5c23fe7..3f57881b74e6 100644
--- a/drivers/net/wireless/realtek/rtw89/sar.c
+++ b/drivers/net/wireless/realtek/rtw89/sar.c
@@ -199,7 +199,6 @@ struct rtw89_sar_handler rtw89_sar_handlers[RTW89_SAR_SOURCE_NR] = {
typeof(_dev) _d = (_dev); \
BUILD_BUG_ON(!rtw89_sar_handlers[_s].descr_sar_source); \
BUILD_BUG_ON(!rtw89_sar_handlers[_s].query_sar_config); \
- lockdep_assert_wiphy(_d->hw->wiphy); \
_d->sar._cfg_name = *(_cfg_data); \
_d->sar.src = _s; \
} while (0)
--
2.49.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* RE: [PATCH rtw-next] wifi: rtw89: sar: drop assertion from rtw89_sar_set_src()
2025-06-03 15:26 [PATCH rtw-next] wifi: rtw89: sar: drop assertion from rtw89_sar_set_src() Fedor Pchelkin
@ 2025-06-04 1:28 ` Ping-Ke Shih
2025-06-04 16:06 ` Fedor Pchelkin
0 siblings, 1 reply; 3+ messages in thread
From: Ping-Ke Shih @ 2025-06-04 1:28 UTC (permalink / raw)
To: Fedor Pchelkin
Cc: Zong-Zhe Yang, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org
Fedor Pchelkin <pchelkin@ispras.ru> wrote:
> Urgh, this one wasn't caught as my system doesn't have any SAR available
> from ACPI. But it would be falsely triggered, too. If I saw it earlier,
> I'd better prepared this as a followup patch in a series though..
>
Good catch.
There are two consumers. One is rtw89_apply_sar_acpi() which should not
assert wiphy_lock, but the other rtw89_apply_sar_common() can be. As I know,
the assertion is added for the latter one initially.
Another way is to assert the lock under condition of
test_bit(RTW89_FLAG_PROBE_DONE, rtwdev->flags)
> drivers/net/wireless/realtek/rtw89/sar.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/sar.c b/drivers/net/wireless/realtek/rtw89/sar.c
> index 33a4b5c23fe7..3f57881b74e6 100644
> --- a/drivers/net/wireless/realtek/rtw89/sar.c
> +++ b/drivers/net/wireless/realtek/rtw89/sar.c
> @@ -199,7 +199,6 @@ struct rtw89_sar_handler rtw89_sar_handlers[RTW89_SAR_SOURCE_NR] = {
> typeof(_dev) _d = (_dev); \
> BUILD_BUG_ON(!rtw89_sar_handlers[_s].descr_sar_source); \
> BUILD_BUG_ON(!rtw89_sar_handlers[_s].query_sar_config); \
> - lockdep_assert_wiphy(_d->hw->wiphy); \
> _d->sar._cfg_name = *(_cfg_data); \
> _d->sar.src = _s; \
> } while (0)
> --
> 2.49.0
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH rtw-next] wifi: rtw89: sar: drop assertion from rtw89_sar_set_src()
2025-06-04 1:28 ` Ping-Ke Shih
@ 2025-06-04 16:06 ` Fedor Pchelkin
0 siblings, 0 replies; 3+ messages in thread
From: Fedor Pchelkin @ 2025-06-04 16:06 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Zong-Zhe Yang, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org
On Wed, 04. Jun 01:28, Ping-Ke Shih wrote:
> Fedor Pchelkin <pchelkin@ispras.ru> wrote:
> > Urgh, this one wasn't caught as my system doesn't have any SAR available
> > from ACPI. But it would be falsely triggered, too. If I saw it earlier,
> > I'd better prepared this as a followup patch in a series though..
> >
>
> Good catch.
>
> There are two consumers. One is rtw89_apply_sar_acpi() which should not
> assert wiphy_lock, but the other rtw89_apply_sar_common() can be. As I know,
> the assertion is added for the latter one initially.
>
> Another way is to assert the lock under condition of
> test_bit(RTW89_FLAG_PROBE_DONE, rtwdev->flags)
>
Ok, thanks! So I'll fold this reworked patch and the other one [1] into
a series and send them out.
[1]: https://lore.kernel.org/linux-wireless/20250603144614.175003-1-pchelkin@ispras.ru/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-06-04 16:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-03 15:26 [PATCH rtw-next] wifi: rtw89: sar: drop assertion from rtw89_sar_set_src() Fedor Pchelkin
2025-06-04 1:28 ` Ping-Ke Shih
2025-06-04 16:06 ` Fedor Pchelkin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox