netdev - Re: assert_cfg80211_lock warning with Linux v3.5-8833-g2d53492

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120801161959.GC22963@thinkpad-t410>
Date:	Wed, 1 Aug 2012 11:19:59 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Arend van Spriel <arend@...adcom.com>,
	"John W. Linville" <linville@...driver.com>,
	Josh Boyer <jwboyer@...hat.com>,
	Brett Rudley <brudley@...adcom.com>,
	Roland Vossen <rvossen@...adcom.com>,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: assert_cfg80211_lock warning with Linux v3.5-8833-g2d53492

On Wed, Aug 01, 2012 at 05:53:58PM +0200, Johannes Berg wrote:
> On Wed, 2012-08-01 at 17:51 +0200, Arend van Spriel wrote:
> > On 08/01/2012 05:38 PM, Arend van Spriel wrote:
> > >> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
> > >> > 
> > >> > It looks like those calls were added in mid-June.
> > >> > 
> > > I think mid-june sounds about right. We never observed the warning when
> > > changes to use regulatory infrastructure were tested/reviewed. Should
> > > this precondition be mentioned in cfg80211.h?
> > > 
> > > Gr. AvS
> > 
> > Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
> > another solution is needed.
> 
> Yeah I was going to say -- how can it possibly access that? It seems
> that in some patch the API got broken, it should be taking the lock or
> whatever ... I'll leave it to Luis to sort out though :-P

In other drivers freq_reg_info only seems to get used by the regulatory
notifiers, which get called with the lock held. brcmsmac is wanting to
know whether or not OFDM is allowed when setting the channel though, and
I didn't find that information anywhere outside the regulatory
information. If there's another way then calling freq_reg_info() could
be avoided. Or maybe we could add an OFDM flag to the channel
information?

Seth

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html