pull-request: mac80211 2021-01-18.2

pull-request: mac80211 2021-01-18.2

[Johannes Berg]

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(-)

Re: pull-request: mac80211 2021-01-18.2

[patchwork-bot+netdevbpf]

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

Re: pull-request: mac80211 2021-01-18.2

[Johannes Berg]

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

Re: pull-request: mac80211 2021-01-18.2

[Jakub Kicinski]

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?

Re: pull-request: mac80211 2021-01-18.2

[Johannes Berg]

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

Re: pull-request: mac80211 2021-01-18.2

[Hans de Goede]

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(-)
> 
> 

Re: pull-request: mac80211 2021-01-18.2

[Johannes Berg]

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

RE: pull-request: mac80211 2021-01-18.2

[Peer, Ilan]

> -----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.

Re: pull-request: mac80211 2021-01-18.2

[Hans de Goede]

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

RE: pull-request: mac80211 2021-01-18.2

[Peer, Ilan]

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.

Re: pull-request: mac80211 2021-01-18.2

[Johannes Berg]

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

Re: pull-request: mac80211 2021-01-18.2

[Hans de Goede]

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

Re: pull-request: mac80211 2021-01-18.2

[Johannes Berg]

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

Re: pull-request: mac80211 2021-01-18.2

[Hans de Goede]

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

Re: pull-request: mac80211 2021-01-18.2

[Johannes Berg]

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