[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZTfgJCBxsNv3bVjv@hovoldconsulting.com>
Date: Tue, 24 Oct 2023 17:17:56 +0200
From: Johan Hovold <johan@...nel.org>
To: Kalle Valo <kvalo@...nel.org>
Cc: Johan Hovold <johan+linaro@...nel.org>,
Jeff Johnson <quic_jjohnson@...cinc.com>,
ath11k@...ts.infradead.org, linux-wireless@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] wifi: ath11k: fix event locking
On Tue, Oct 24, 2023 at 05:07:38PM +0300, Kalle Valo wrote:
> Johan Hovold <johan+linaro@...nel.org> writes:
>
> > RCU lockdep reported suspicious RCU usage when accessing the temperature
> > sensor. Inspection revealed that the DFS radar event code was also
> > missing the required RCU read-side critical section marking.
> >
> > Johan
> >
> >
> > Changes in v2
> > - add the missing rcu_read_unlock() to an
> > ath11k_wmi_pdev_temperature_event() error path as noticed by Jeff
> >
> >
> > Johan Hovold (2):
> > wifi: ath11k: fix temperature event locking
> > wifi: ath11k: fix dfs radar event locking
>
> Thanks for the fixes. I really like using lockdep_assert_held() to
> document if a function requires some lock held, is there anything
> similar for RCU?
Not really, but the checking is instead built into the primitives like
rcu_dereference() and enabled whenever CONFIG_PROVE_RCU is set.
For some special cases, we have open-coded checks like:
RCU_LOCKDEP_WARN(!rcu_read_lock_held());
which similarly depend on CONFIG_PROVE_RCU or simply
WARN_ON_ONCE(!rcu_read_lock_held());
Johan
Powered by blists - more mailing lists