From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-01-18 20:50:02
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(-)
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.
[...]
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-01-20 18:01:04
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
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-01-20 20:43:28
On Wed, 2021-01-20 at 12:37 -0800, Jakub Kicinski wrote:
On Wed, 20 Jan 2021 18:59:21 +0100 Johannes Berg wrote:
quoted
Hi Jakub,
quoted
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
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-01-20 20:49:07
On Wed, 20 Jan 2021 18:59:21 +0100 Johannes Berg wrote:
Hi Jakub,
quoted
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?
From: Hans de Goede <hidden> Date: 2021-01-23 21:33:31
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
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
From: Peer, Ilan <hidden> Date: 2021-01-24 09:28:21
-----Original Message-----
From: Johannes Berg <johannes@sipsolutions.net>
Sent: Sunday, January 24, 2021 00:16
To: Hans de Goede <redacted>; netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org; Peer, Ilan <redacted>;
Coelho, Luciano [off-list ref]
Subject: Re: pull-request: mac80211 2021-01-18.2
On Sat, 2021-01-23 at 22:31 +0100, Hans de Goede wrote:
From: Hans de Goede <hidden> Date: 2021-01-24 10:56:28
Hi,
On 1/24/21 10:12 AM, Peer, Ilan wrote:
quoted
-----Original Message-----
From: Johannes Berg <johannes@sipsolutions.net>
Sent: Sunday, January 24, 2021 00:16
To: Hans de Goede <redacted>; netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org; Peer, Ilan <redacted>;
Coelho, Luciano [off-list ref]
Subject: Re: pull-request: mac80211 2021-01-18.2
On Sat, 2021-01-23 at 22:31 +0100, Hans de Goede wrote:
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
From: Peer, Ilan <hidden> Date: 2021-01-24 13:04:41
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.
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-01-25 09:51:13
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.
From: Hans de Goede <hidden> Date: 2021-01-26 05:06:42
Hi,
On 1/25/21 1:40 PM, Johannes Berg wrote:
Hi,
quoted
quoted
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.
quoted
quoted
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
From: Hans de Goede <hidden> Date: 2021-01-26 20:36:47
Hi,
On 1/25/21 10:47 AM, Johannes Berg wrote:
Hi,
Sorry, apparently we have two threads.
quoted
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
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-01-26 20:42:31
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
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-01-26 20:52:19
Hi,
quoted
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.
quoted
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