[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <09ddb018-7093-2e2a-c84b-148889f7f06d@broadcom.com>
Date: Tue, 23 May 2017 09:19:26 +0200
From: Arend Van Spriel <arend.vanspriel@...adcom.com>
To: Johannes Berg <johannes@...solutions.net>,
Sander Eikelenboom <linux@...elenboom.it>
Cc: linux-wireless <linux-wireless@...r.kernel.org>,
netdev@...r.kernel.org
Subject: Re: 4.12-RC2 BUG: scheduling while atomic: irq/47-iwlwifi
On 22-5-2017 23:04, Johannes Berg wrote:
> Hi Arend,
>
> Sorry, I forgot that the original message wasn't Cc'ed to the wireless
> list, only netdev.
That explains. Not subscribed to that.
>> +++ b/net/wireless/scan.c
>> @@ -322,9 +322,7 @@ static void cfg80211_del_sched_scan_req(struct
>> cfg80211_regi
>> {
>> struct cfg80211_sched_scan_request *pos;
>>
>> - ASSERT_RTNL();
>> -
>> - list_for_each_entry(pos, &rdev->sched_scan_req_list, list) {
>> + list_for_each_entry_rcu(pos, &rdev->sched_scan_req_list,
>> list) {
>
> [snip]
>
> This looks fine, but perhaps in the above we should have some kind of
> locking assertion, e.g.
>
> WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_rtnl_is_held());
Thought about something like this after sending the email. So there are
two call sites. One for scheduled scan results notification and one in
scheduled scan stop scenario. So for the latter it is not needed to use
the rcu_read_lock() as it should have RTNL lock hence the two checks above?
Will create a formal patch.
Regards,
Arend
Powered by blists - more mailing lists