linux-kernel - Re: [1/2] brcmfmac: delete interface directly in code that sent fw request

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 for Android: free password hash cracker in your pocket

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

Date:	Fri,  8 Jul 2016 13:46:05 +0000 (UTC)
From:	Kalle Valo <kvalo@...eaurora.org>
To:	Rafał Miłecki <zajec5@...il.com>
Cc:	Rafał Miłecki <zajec5@...il.com>,
	Arend van Spriel <arend.vanspriel@...adcom.com>,
	Franky Lin <franky.lin@...adcom.com>,
	Hante Meuleman <hante.meuleman@...adcom.com>,
	Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
	"Franky (Zhenhui) Lin" <frankyl@...adcom.com>,
	linux-wireless@...r.kernel.org (open list:BROADCOM BRCM80211
	IEEE802.11n WIRELESS DRIVER),
	brcm80211-dev-list.pdl@...adcom.com (open list:BROADCOM BRCM80211
	IEEE802.11n WIRELESS DRIVER),
	netdev@...r.kernel.org (open list:NETWORKING DRIVERS),
	linux-kernel@...r.kernel.org (open list)
Subject: Re: [1/2] brcmfmac: delete interface directly in code that sent fw
 request

Rafał Miłecki wrote:
> So far when receiving event about in-firmware-interface removal our
> event worker was notifying listener and afterwards it was removing Linux
> interface.
> 
> First of all it was resulting in slightly unexpected order. The listener
> (del_virtual_intf callback) was (usually) returning with success before
> we even called unregister_netdev(ice).
> 
> Please note this couldn't be simply fixed by changing order of calls in
> brcmf_fweh_handle_if_event as unregistering interface earlier could free
> struct brcmf_if.
> 
> Another problem of current implementation are possible lockups. Focus on
> the time slot between calling event handler and removing Linux
> interface. During that time original caller may leave (unlocking rtnl
> semaphore) *and* another call to the same code may be done (locking it
> again). If that happens our event handler will stuck at removing Linux
> interface, it won't handle another event and will block process holding
> rtnl lock.
> 
> This can be simply solved by unregistering interface in a proper
> callback, right after receiving confirmation event from firmware. This
> only required modifying worker to don't unregister on its own if there
> is someone waiting for the event.
> 
> Signed-off-by: Rafał Miłecki <zajec5@...il.com>

Thanks, 2 patches applied to wireless-drivers-next.git:

a63b09872c1d brcmfmac: delete interface directly in code that sent fw request
dba8fbc67ecd brcmfmac: support removing AP interfaces with "interface_remove"

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9206157/