From: Ben Greear <greearb@candelatech.com> To: Johannes Berg <johannes@sipsolutions.net>, Michal Kazior <michal.kazior@tieto.com> Cc: linux-wireless <linux-wireless@vger.kernel.org>, "ath10k@lists.infradead.org" <ath10k@lists.infradead.org> Subject: Re: [PATCH 1/2] mac80211: do not iterate active interfaces when in re-configure Date: Mon, 05 Dec 2016 07:06:35 -0800 [thread overview] Message-ID: <5845827B.2000000@candelatech.com> (raw) In-Reply-To: <1480950054.31788.36.camel@sipsolutions.net> On 12/05/2016 07:00 AM, Johannes Berg wrote: > On Mon, 2016-12-05 at 06:57 -0800, Ben Greear wrote: > >> I think clearing sdata-in-driver would fix the ath10k problem, at >> least, but I was afraid it would break something else in mac80211 or >> maybe in other thick firmware drivers. > > It's pretty much an internal thing - not sure what it'd break. OTOH, > some drivers might actually assume that iterating finds them all, if > they never clear the data even across a restart? > >> One way or another, we cannot be iterating over interfaces while >> the interfaces are at the same time being (re)added. > > Well, we obviously *can* be, and we do in fact do that - it's just that > ath10k specifically has issues with the data it's putting there, no? It causes races that appear to be very difficult to resolve in the driver alone. On normal bringup of an interface, the sdata-in-driver flag is only set at the bottom of the add-interface. In case of re-config, the flag is already set, and never cleared, so behaviour is different w/regard to the iterate. > >> Maybe mac80211 should explicitly remove all interfaces from the >> driver during crash recovery? > > I don't think that'll work. Removing them would interact with the > firmware, which is dead, etc. That'd just cause trouble. That issue already causes trouble and is dealt with in ath10k, I think, but clearing the flag in mac80211 would probably be enough to fix the iterate logic. >> And the behaviour needs to be clearly documented somewhere >> easy to find so that we can think about and program to the correct >> API behaviour. > > We assume that the driver resets all its internal state - this whole > interface iteration is a corner case we hadn't considered, I suppose. Yeah, tricky beastie. I think the txq issue is also part of this since there are references up in mac80211 and also down in ath10k. Part of my hack to clean up that crash might be resolved by mac80211 doing better cleanup API when firmware crashes. Thanks, Ben > > johannes > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com
WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com> To: Johannes Berg <johannes@sipsolutions.net>, Michal Kazior <michal.kazior@tieto.com> Cc: linux-wireless <linux-wireless@vger.kernel.org>, "ath10k@lists.infradead.org" <ath10k@lists.infradead.org> Subject: Re: [PATCH 1/2] mac80211: do not iterate active interfaces when in re-configure Date: Mon, 05 Dec 2016 07:06:35 -0800 [thread overview] Message-ID: <5845827B.2000000@candelatech.com> (raw) In-Reply-To: <1480950054.31788.36.camel@sipsolutions.net> On 12/05/2016 07:00 AM, Johannes Berg wrote: > On Mon, 2016-12-05 at 06:57 -0800, Ben Greear wrote: > >> I think clearing sdata-in-driver would fix the ath10k problem, at >> least, but I was afraid it would break something else in mac80211 or >> maybe in other thick firmware drivers. > > It's pretty much an internal thing - not sure what it'd break. OTOH, > some drivers might actually assume that iterating finds them all, if > they never clear the data even across a restart? > >> One way or another, we cannot be iterating over interfaces while >> the interfaces are at the same time being (re)added. > > Well, we obviously *can* be, and we do in fact do that - it's just that > ath10k specifically has issues with the data it's putting there, no? It causes races that appear to be very difficult to resolve in the driver alone. On normal bringup of an interface, the sdata-in-driver flag is only set at the bottom of the add-interface. In case of re-config, the flag is already set, and never cleared, so behaviour is different w/regard to the iterate. > >> Maybe mac80211 should explicitly remove all interfaces from the >> driver during crash recovery? > > I don't think that'll work. Removing them would interact with the > firmware, which is dead, etc. That'd just cause trouble. That issue already causes trouble and is dealt with in ath10k, I think, but clearing the flag in mac80211 would probably be enough to fix the iterate logic. >> And the behaviour needs to be clearly documented somewhere >> easy to find so that we can think about and program to the correct >> API behaviour. > > We assume that the driver resets all its internal state - this whole > interface iteration is a corner case we hadn't considered, I suppose. Yeah, tricky beastie. I think the txq issue is also part of this since there are references up in mac80211 and also down in ath10k. Part of my hack to clean up that crash might be resolved by mac80211 doing better cleanup API when firmware crashes. Thanks, Ben > > johannes > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2016-12-05 15:20 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-02 2:29 [PATCH 1/2] mac80211: do not iterate active interfaces when in re-configure greearb 2016-12-02 2:29 ` greearb 2016-12-02 2:30 ` [PATCH 2/2] ath10k: work-around for stale txq in ar->txqs greearb 2016-12-02 2:30 ` greearb 2016-12-05 8:13 ` [PATCH 1/2] mac80211: do not iterate active interfaces when in re-configure Michal Kazior 2016-12-05 8:13 ` Michal Kazior 2016-12-05 13:52 ` Johannes Berg 2016-12-05 13:52 ` Johannes Berg 2016-12-05 14:57 ` Ben Greear 2016-12-05 14:57 ` Ben Greear 2016-12-05 15:00 ` Johannes Berg 2016-12-05 15:00 ` Johannes Berg 2016-12-05 15:06 ` Ben Greear [this message] 2016-12-05 15:06 ` Ben Greear 2016-12-05 17:23 ` Adrian Chadd 2016-12-05 17:23 ` Adrian Chadd
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5845827B.2000000@candelatech.com \ --to=greearb@candelatech.com \ --cc=ath10k@lists.infradead.org \ --cc=johannes@sipsolutions.net \ --cc=linux-wireless@vger.kernel.org \ --cc=michal.kazior@tieto.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.