Path: csiph.com!news.freedyn.net!aioe.org!gothmog.csi.it!bofh.it!news.nic.it!robomod From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Newsgroups: linux.kernel Subject: Re: [PATCH RFC 1/2] brcmfmac: remove interface before notifying listener Date: Sun, 19 Jun 2016 00:50:02 +0200 Message-ID: References: X-Original-To: Arend van Spriel Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iwdHwDAKYJvPEJR21P5twqz5nGQ46DMU0MZN5awsVU4=; b=czsBGlINe0KRlOFnDbUVpSfcdtB/h6qLCl9D/TGgs5f+n0EP+w68T6NP9etrNrgRxJ bpRamSoZNtpNLGJCjx1P0ngRc3vyI+Nwa/WUnojqRG3dSSHWgfWbrPiHs5iSuzqLS1nQ OvoHrjDymjl7mEDvr1x58vLOYG8Uwo6CGR1LjBIyRfmc+pw0zTvWQ1XG01sMkF/cHYzX l6fKc8+6lQq03eQgGFhfw13GVAneul58yDLHoNLehlCzpgcbDmU37ce93I3P39wGjxRV LZXJN+mUqcs3igOJJPZudXvD9WiouGrQIUCXe2QUNKpvgM9J2RA0H5CUxZma2wCEc3tR 7ABw== X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iwdHwDAKYJvPEJR21P5twqz5nGQ46DMU0MZN5awsVU4=; b=SdN9v5jpPEzWpF6GRrtrdI3O4eZzPe4v735fNtR66obATmU5fwpEAwYpGUE7rSoc0m YNbCdKphh0hA7uKIuCbBHfE40HujOvp8KVYe7vxI+EOym58qFYMLhWzl05vGKc6PI2S7 v9l5/pu5do0NhaYAFMGlBwbRLv69DGiAxs9bLIp5+MBnnBWBfwoWGd8sQjJhBwpG799I nSalb8QA+NfgNBme1cDJXDDQLMij1sdNQGhUO1L5BJuf9Mo0TWI3mCSbRO/9TSe7g0IH rkLAOdpNxyHUtl4zr84MqN5v4I5/M54jCRmrk5kDexHqis1CysYOsF8aVJE161yoNCNy nc+w== X-Gm-Message-State: ALyK8tJia25oFSLRq8pEwzEjMTY9LuN4GQJoReRZh5VsG7iWtp6pYw+DBZUVWXoVY4LEcMlrOldB5TjuzbqW1w== X-Received: by 10.157.44.73 with SMTP id f67mr5301297otb.116.1466289779468; Sat, 18 Jun 2016 15:42:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: robomod@news.nic.it List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Approved: robomod@news.nic.it Lines: 41 Organization: linux.* mail to news gateway X-Original-Cc: Kalle Valo , Franky Lin , Hante Meuleman , Pieter-Paul Giesberts , "Franky (Zhenhui) Lin" , "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" , "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" , "open list:NETWORKING DRIVERS" , open list X-Original-Date: Sun, 19 Jun 2016 00:42:58 +0200 X-Original-Message-ID: X-Original-References: <1466273932-11554-1-git-send-email-zajec5@gmail.com> <5765A06C.3040005@broadcom.com> X-Original-Sender: linux-kernel-owner@vger.kernel.org Xref: csiph.com linux.kernel:1425869 On 18 June 2016 at 23:58, Rafał Miłecki wrote: > On 18 June 2016 at 21:26, Arend van Spriel wrote: >> On 18-06-16 20:18, Rafał Miłecki wrote: >>> So far when receiving event about in-firmware-interface removal we were >>> notifying our listener and afterwards we were removing Linux interface. >>> >> >> [snip] >> >>> >>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c >>> index 9da7a4c..5fd1886 100644 >>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c >>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c >>> @@ -18,6 +18,7 @@ >>> #include "brcmu_wifi.h" >>> #include "brcmu_utils.h" >>> >>> +#include "cfg80211.h" >>> #include "core.h" >>> #include "debug.h" >>> #include "tracepoint.h" >>> @@ -180,10 +181,16 @@ static void brcmf_fweh_handle_if_event(struct brcmf_pub *drvr, >>> if (ifp && ifevent->action == BRCMF_E_IF_CHANGE) >>> brcmf_fws_reset_interface(ifp); >>> >>> - err = brcmf_fweh_call_event_handler(ifp, emsg->event_code, emsg, data); >> >> The reason for doing this first is because we are passing the ifp, which >> is netdev_priv(ifp->ndev). In brcmf_remove_interface() we only >> unregister the netdev, which will end up (after scheduling) in >> brcmf_free_netdev() thus freeing the ifp. By moving the event handler >> function ifp may be stale already. > > Good catch. What about making brcmf_fweh_call_event_handler work > without ifp? Would that be OK then? Maybe I have even better idea. What about handling Linux interface removal in the code waiting for BRCMF_E_IF_DEL? We already do something like that in case of BRCMF_E_IF_ADD (it is brcmf_ap_add_vif that calls brcmf_net_attach).