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.
>
> [...]
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/[email protected]/
But it introduces a deadlock. See:
https://lore.kernel.org/linux-wireless/[email protected]/
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/[email protected]/
>
> But it introduces a deadlock. See:
>
> https://lore.kernel.org/linux-wireless/[email protected]/
>
> 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 <[email protected]>
> Sent: Sunday, January 24, 2021 00:16
> To: Hans de Goede <[email protected]>; [email protected]
> Cc: [email protected]; Peer, Ilan <[email protected]>;
> Coelho, Luciano <[email protected]>
> 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
> > [email protected]/
> >
> > 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 <[email protected]>
>> Sent: Sunday, January 24, 2021 00:16
>> To: Hans de Goede <[email protected]>; [email protected]
>> Cc: [email protected]; Peer, Ilan <[email protected]>;
>> Coelho, Luciano <[email protected]>
>> 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
>>> [email protected]/
>>>
>>> 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 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
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
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,
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