| Message ID | 20210118204750.7243-1-johannes@sipsolutions.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | bde2c0af6141702580a2ccebc396041660d127ef |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | pull-request: mac80211 2021-01-18.2 | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Series ignored based on subject |
Hello: This pull request was applied to netdev/net.git (refs/heads/master): On Mon, 18 Jan 2021 21:47:49 +0100 you wrote: > Hi, > > New try, dropped the 160 MHz CSA patch for now that has the sparse > issue since people are waiting for the kernel-doc fixes. > > Please pull and let me know if there's any problem. > > [...] Here is the summary with links: - pull-request: mac80211 2021-01-18.2 https://git.kernel.org/netdev/net/c/bde2c0af6141 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Hi Jakub,
> This pull request was applied to netdev/net.git (refs/heads/master):
Since you pulled this now, question:
I have some pending content for mac80211-next/net-next that either
conflicts with or requires a fix from here, or such.
Could you pull net into net-next, so I can get it into mac80211-next? Or
do you prefer another approach here? I could also double-apply the
single patch, or pull myself but then we'd get a lot of net content into
net-next only via mac80211-next which seems odd.
Thanks,
johannes
On Wed, 20 Jan 2021 18:59:21 +0100 Johannes Berg wrote: > Hi Jakub, > > > This pull request was applied to netdev/net.git (refs/heads/master): > > Since you pulled this now, question: > > I have some pending content for mac80211-next/net-next that either > conflicts with or requires a fix from here, or such. > > Could you pull net into net-next, so I can get it into mac80211-next? Or > do you prefer another approach here? I could also double-apply the > single patch, or pull myself but then we'd get a lot of net content into > net-next only via mac80211-next which seems odd. Just merged net -> net-next, you can do your thing :) Out of curiosity are you going to rebase mac80211-next or send a PR, fast forward and then apply the conflicting patches?
On Wed, 2021-01-20 at 12:37 -0800, Jakub Kicinski wrote: > On Wed, 20 Jan 2021 18:59:21 +0100 Johannes Berg wrote: > > Hi Jakub, > > > > > This pull request was applied to netdev/net.git (refs/heads/master): > > > > Since you pulled this now, question: > > > > I have some pending content for mac80211-next/net-next that either > > conflicts with or requires a fix from here, or such. > > > > Could you pull net into net-next, so I can get it into mac80211-next? Or > > do you prefer another approach here? I could also double-apply the > > single patch, or pull myself but then we'd get a lot of net content into > > net-next only via mac80211-next which seems odd. > > Just merged net -> net-next, you can do your thing :) Ok cool, thanks. > Out of curiosity are you going to rebase mac80211-next or send a PR, > fast forward and then apply the conflicting patches? Normally I'd send a PR for it and then fast-forward. However, it's actually empty at the moment, so I'm just going to fast- forward it to net-next before I apply the next patches :-) johannes
On 1/18/21 9:47 PM, Johannes Berg wrote: > Hi, > > New try, dropped the 160 MHz CSA patch for now that has the sparse > issue since people are waiting for the kernel-doc fixes. > > Please pull and let me know if there's any problem. > > Thanks, > johannes > > > > The following changes since commit 220efcf9caf755bdf92892afd37484cb6859e0d2: > > Merge tag 'mlx5-fixes-2021-01-07' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux (2021-01-07 19:13:30 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-net-2021-01-18.2 > > for you to fetch changes up to c13cf5c159660451c8fbdc37efb998b198e1d305: > > mac80211: check if atf has been disabled in __ieee80211_schedule_txq (2021-01-14 22:27:38 +0100) > > ---------------------------------------------------------------- > Various fixes: > * kernel-doc parsing fixes > * incorrect debugfs string checks > * locking fix in regulatory > * some encryption-related fixes > > ---------------------------------------------------------------- > Felix Fietkau (3): > mac80211: fix fast-rx encryption check > mac80211: fix encryption key selection for 802.3 xmit > mac80211: do not drop tx nulldata packets on encrypted links > > Ilan Peer (1): > cfg80211: Save the regulatory domain with a lock So I'm afraid that I have some bad news about this patch, it fixes the RCU warning which I reported: https://lore.kernel.org/linux-wireless/20210104170713.66956-1-hdegoede@redhat.com/ But it introduces a deadlock. See: https://lore.kernel.org/linux-wireless/d839ab62-e4bc-56f0-d861-f172bf19c4b3@redhat.com/ for details. Note we really should fix this new deadlock before 5.11 is released. This is worse then the RCU warning which this patch fixes. Regards, Hans > > Johannes Berg (1): > cfg80211/mac80211: fix kernel-doc for SAR APIs > > Lorenzo Bianconi (1): > mac80211: check if atf has been disabled in __ieee80211_schedule_txq > > Mauro Carvalho Chehab (1): > cfg80211: fix a kerneldoc markup > > Shayne Chen (1): > mac80211: fix incorrect strlen of .write in debugfs > > include/net/cfg80211.h | 5 ++++- > include/net/mac80211.h | 1 + > net/mac80211/debugfs.c | 44 ++++++++++++++++++++------------------------ > net/mac80211/rx.c | 2 ++ > net/mac80211/tx.c | 31 +++++++++++++++++-------------- > net/wireless/reg.c | 11 ++++++++++- > 6 files changed, 54 insertions(+), 40 deletions(-) > >
On Sat, 2021-01-23 at 22:31 +0100, Hans de Goede wrote: > > So I'm afraid that I have some bad news about this patch, it fixes > the RCU warning which I reported: > > https://lore.kernel.org/linux-wireless/20210104170713.66956-1-hdegoede@redhat.com/ > > But it introduces a deadlock. See: > > https://lore.kernel.org/linux-wireless/d839ab62-e4bc-56f0-d861-f172bf19c4b3@redhat.com/ > > for details. Note we really should fix this new deadlock before 5.11 > is released. This is worse then the RCU warning which this patch fixes. Ouch. Thanks for the heads-up. I guess I'll revert both patches for now, unless we can quickly figure out a way to get all these paths in order. Thanks, johannes
> -----Original Message----- > From: Johannes Berg <johannes@sipsolutions.net> > Sent: Sunday, January 24, 2021 00:16 > To: Hans de Goede <hdegoede@redhat.com>; netdev@vger.kernel.org > Cc: linux-wireless@vger.kernel.org; Peer, Ilan <ilan.peer@intel.com>; > Coelho, Luciano <luciano.coelho@intel.com> > Subject: Re: pull-request: mac80211 2021-01-18.2 > > On Sat, 2021-01-23 at 22:31 +0100, Hans de Goede wrote: > > > > So I'm afraid that I have some bad news about this patch, it fixes the > > RCU warning which I reported: > > > > https://lore.kernel.org/linux-wireless/20210104170713.66956-1-hdegoede > > @redhat.com/ > > > > But it introduces a deadlock. See: > > > > https://lore.kernel.org/linux-wireless/d839ab62-e4bc-56f0-d861-f172bf1 > > 9c4b3@redhat.com/ > > > > for details. Note we really should fix this new deadlock before 5.11 > > is released. This is worse then the RCU warning which this patch fixes. > > Ouch. Thanks for the heads-up. I guess I'll revert both patches for now, > unless we can quickly figure out a way to get all these paths in order. > Thanks Hans and Johannes for handling this. I'll try to come up with a solution. Regards, Ilan.
Hi, On 1/24/21 10:12 AM, Peer, Ilan wrote: >> -----Original Message----- >> From: Johannes Berg <johannes@sipsolutions.net> >> Sent: Sunday, January 24, 2021 00:16 >> To: Hans de Goede <hdegoede@redhat.com>; netdev@vger.kernel.org >> Cc: linux-wireless@vger.kernel.org; Peer, Ilan <ilan.peer@intel.com>; >> Coelho, Luciano <luciano.coelho@intel.com> >> Subject: Re: pull-request: mac80211 2021-01-18.2 >> >> On Sat, 2021-01-23 at 22:31 +0100, Hans de Goede wrote: >>> >>> So I'm afraid that I have some bad news about this patch, it fixes the >>> RCU warning which I reported: >>> >>> https://lore.kernel.org/linux-wireless/20210104170713.66956-1-hdegoede >>> @redhat.com/ >>> >>> But it introduces a deadlock. See: >>> >>> https://lore.kernel.org/linux-wireless/d839ab62-e4bc-56f0-d861-f172bf1 >>> 9c4b3@redhat.com/ >>> >>> for details. Note we really should fix this new deadlock before 5.11 >>> is released. This is worse then the RCU warning which this patch fixes. >> >> Ouch. Thanks for the heads-up. I guess I'll revert both patches for now, >> unless we can quickly figure out a way to get all these paths in order. >> > > Thanks Hans and Johannes for handling this. I'll try to come up with a solution. Great, thank you for looking into this. Let me know if you have a patch which you want me to test on a RTL8723BS adapter. One thing which I forgot to mention earlier, it is not just lockdep complaining this appears to be a real deadlock, the wifi no longer functions, where as it does function with the patch drops. Regards, Hans
Hi, > Great, thank you for looking into this. Let me know if you have a patch which > you want me to test on a RTL8723BS adapter. > > One thing which I forgot to mention earlier, it is not just lockdep complaining > this appears to be a real deadlock, the wifi no longer functions, where as it > does function with the patch drops. > Agree. Johannes, Based on the latest changes you introduced in mac80211-next, the RTNL lock is not really required and can be removed. Would this be sufficient, or would you prefer a fix regardless of these changes? Thanks in advance, Ilan.
Hi, Sorry, apparently we have two threads. > Great, thank you for looking into this. Let me know if you have a patch > which you want me to test on a RTL8723BS adapter. Could you test this instead? https://p.sipsolutions.net/235c352b8ae5db88.txt I don't have that much sympathy for a staging driver that's clearly doing things differently than it was intended (the documentation states that the function should be called only before wiphy_register(), not during ndo_open). :-) But OTOH, that fix to the driver is simple and looks correct to me since it only ever has a static regdomain, and the notifier does the work of applying it to the channels as well. > One thing which I forgot to mention earlier, it is not just lockdep complaining > this appears to be a real deadlock, the wifi no longer functions, where > as it does function with the patch drops. Right. johannes
Hi, On 1/25/21 10:47 AM, Johannes Berg wrote: > Hi, > > Sorry, apparently we have two threads. > >> Great, thank you for looking into this. Let me know if you have a patch >> which you want me to test on a RTL8723BS adapter. > > Could you test this instead? > > https://p.sipsolutions.net/235c352b8ae5db88.txt > > > I don't have that much sympathy for a staging driver that's clearly > doing things differently than it was intended (the documentation states > that the function should be called only before wiphy_register(), not > during ndo_open). :-) I completely understand and I already was worried that this might be a staging-driver issue, which is why I mentioned this was with a staging driver in the more detailed bug-report email. > But OTOH, that fix to the driver is simple and looks correct to me since > it only ever has a static regdomain, and the notifier does the work of > applying it to the channels as well. So I've given your fix a quick try and it leads to a NULL pointer deref. But now that you've given me a lead on how to fix this (network/wifi drivers are not really me expertise) I can take a shot at seeing if I can fix the NULL pointer deref. I Hope to get back to you on that later today. Regards, Hans
Hi, > > I don't have that much sympathy for a staging driver that's clearly > > doing things differently than it was intended (the documentation states > > that the function should be called only before wiphy_register(), not > > during ndo_open). :-) > > I completely understand and I already was worried that this might be > a staging-driver issue, which is why I mentioned this was with a > staging driver in the more detailed bug-report email. I guess I missed that, but no worries. > > But OTOH, that fix to the driver is simple and looks correct to me since > > it only ever has a static regdomain, and the notifier does the work of > > applying it to the channels as well. > > So I've given your fix a quick try and it leads to a NULL pointer deref. Ouch. Oh. I see, that driver is *really* stupid, trying to get to the wiphy from the adapter, but going through the wdev instead ... ouch. Wow are these pointers a mess in that driver ... Something like this, perhaps? https://p.sipsolutions.net/4400d9a3b7b800bb.txt johannes
Hi, On 1/25/21 1:40 PM, Johannes Berg wrote: > Hi, > >>> I don't have that much sympathy for a staging driver that's clearly >>> doing things differently than it was intended (the documentation states >>> that the function should be called only before wiphy_register(), not >>> during ndo_open). :-) >> >> I completely understand and I already was worried that this might be >> a staging-driver issue, which is why I mentioned this was with a >> staging driver in the more detailed bug-report email. > > I guess I missed that, but no worries. > >>> But OTOH, that fix to the driver is simple and looks correct to me since >>> it only ever has a static regdomain, and the notifier does the work of >>> applying it to the channels as well. >> >> So I've given your fix a quick try and it leads to a NULL pointer deref. > > Ouch. Oh. I see, that driver is *really* stupid, trying to get to the > wiphy from the adapter, but going through the wdev instead ... ouch. > > Wow are these pointers a mess in that driver ... Something like this, > perhaps? > > https://p.sipsolutions.net/4400d9a3b7b800bb.txt Yes this fixes things, thank you that saves me from having to debug the NULL ptr deref. Do you want to submit this to Greg, or shall I (I've already added it to me local tree as a commit with you as the author) ? If you want me to submit it upstream, may I have / add your S-o-b for this ? Regards, Hans
On Mon, 2021-01-25 at 13:59 +0100, Hans de Goede wrote: > Yes this fixes things, thank you that saves me from having to debug > the NULL ptr deref. :) > Do you want to submit this to Greg, or shall I (I've already > added it to me local tree as a commit with you as the author) ? > > If you want me to submit it upstream, may I have / add your S-o-b > for this ? I'll send it out, with a note asking where it should go ... could also take it through my tree since it fixes things from there. johannes
Hi, New try, dropped the 160 MHz CSA patch for now that has the sparse issue since people are waiting for the kernel-doc fixes. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit 220efcf9caf755bdf92892afd37484cb6859e0d2: Merge tag 'mlx5-fixes-2021-01-07' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux (2021-01-07 19:13:30 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-net-2021-01-18.2 for you to fetch changes up to c13cf5c159660451c8fbdc37efb998b198e1d305: mac80211: check if atf has been disabled in __ieee80211_schedule_txq (2021-01-14 22:27:38 +0100) ---------------------------------------------------------------- Various fixes: * kernel-doc parsing fixes * incorrect debugfs string checks * locking fix in regulatory * some encryption-related fixes ---------------------------------------------------------------- Felix Fietkau (3): mac80211: fix fast-rx encryption check mac80211: fix encryption key selection for 802.3 xmit mac80211: do not drop tx nulldata packets on encrypted links Ilan Peer (1): cfg80211: Save the regulatory domain with a lock Johannes Berg (1): cfg80211/mac80211: fix kernel-doc for SAR APIs Lorenzo Bianconi (1): mac80211: check if atf has been disabled in __ieee80211_schedule_txq Mauro Carvalho Chehab (1): cfg80211: fix a kerneldoc markup Shayne Chen (1): mac80211: fix incorrect strlen of .write in debugfs include/net/cfg80211.h | 5 ++++- include/net/mac80211.h | 1 + net/mac80211/debugfs.c | 44 ++++++++++++++++++++------------------------ net/mac80211/rx.c | 2 ++ net/mac80211/tx.c | 31 +++++++++++++++++-------------- net/wireless/reg.c | 11 ++++++++++- 6 files changed, 54 insertions(+), 40 deletions(-)