mbox series

[0/8] cfg80211/mac80211 patches from our internal tree 2024-01-11

Message ID 20240111161746.3978601-1-miriam.rachel.korenblit@intel.com
Headers show
Series cfg80211/mac80211 patches from our internal tree 2024-01-11 | expand

Message

Miri Korenblit Jan. 11, 2024, 4:17 p.m. UTC 
Hi,

A bunch of patches from our internal tree with mac80211 and
cfg80211 changes. It's the usual developement:
features, cleanups and bugfixes.

Thanks,
Miri

Benjamin Berg (1):
  wifi: mac80211: use deflink and fix typo in link ID check

Johannes Berg (7):
  wifi: mac80211_hwsim: advertise 15 simultaneous links
  wifi: mac80211: simplify ieee80211_config_bw() prototype
  wifi: mac80211: remove extra element parsing
  wifi: mac80211: simplify HE capability access
  wifi: mac80211: disallow drivers with HT wider than HE
  wifi: mac80211: fix potential sta-link leak
  wifi: mac80211: don't set bss_conf in parsing

 drivers/net/wireless/virtual/mac80211_hwsim.c |   8 +-
 net/mac80211/main.c                           |  18 +++
 net/mac80211/mlme.c                           | 107 +++++++-----------
 net/mac80211/sta_info.c                       |   5 +-
 net/mac80211/util.c                           |  21 +---
 5 files changed, 72 insertions(+), 87 deletions(-)

Comments

Johannes Berg Jan. 12, 2024, 10:21 a.m. UTC | #1 
On Thu, 2024-01-11 at 15:39 -0500, Jonathan Bither wrote:
> 
> > +			/* currently no support for HE client where HT has 40 MHz but not HT */
> where HT has 40 MHz but not HE?
> 

Yep, typo, thanks. I'll just fix it when I apply it.

(Btw, it'd help to trim quotes - no need to quote _all_ the context
before and after.)

johannes
Kalle Valo Jan. 12, 2024, 1:10 p.m. UTC | #2 
Miri Korenblit <miriam.rachel.korenblit@intel.com> writes:

> +			/* currently no support for HE client where HT has 40 MHz but not HT */
> +			if (iftd->he_cap.has_he &&
> +			    iftd->types_mask & (BIT(NL80211_IFTYPE_STATION) |
> +						BIT(NL80211_IFTYPE_P2P_CLIENT)) &&
> +			    sband->ht_cap.ht_supported &&
> +			    sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40 &&
> +			    !(iftd->he_cap.he_cap_elem.phy_cap_info[0] & he_40_mhz_cap))
> +				return -EINVAL;

Should there be a warning message so that this is noticed if it ever
happens? I don't know.
Jonathan Bither Jan. 12, 2024, 5:27 p.m. UTC | #3 
On 1/12/24 05:21, Johannes Berg wrote:
> On Thu, 2024-01-11 at 15:39 -0500, Jonathan Bither wrote:
>>> +			/* currently no support for HE client where HT has 40 MHz but not HT */
>> where HT has 40 MHz but not HE?
>>
> Yep, typo, thanks. I'll just fix it when I apply it.
No problem.
>
> (Btw, it'd help to trim quotes - no need to quote _all_ the context
> before and after.)
Sure thing, I'll try to be more mindful of this in the future.
>
> johannes
Johannes Berg Jan. 12, 2024, 6:42 p.m. UTC | #4 
On Fri, 2024-01-12 at 15:10 +0200, Kalle Valo wrote:
> Miri Korenblit <miriam.rachel.korenblit@intel.com> writes:
> 
> > +			/* currently no support for HE client where HT has 40 MHz but not HT */
> > +			if (iftd->he_cap.has_he &&
> > +			    iftd->types_mask & (BIT(NL80211_IFTYPE_STATION) |
> > +						BIT(NL80211_IFTYPE_P2P_CLIENT)) &&
> > +			    sband->ht_cap.ht_supported &&
> > +			    sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40 &&
> > +			    !(iftd->he_cap.he_cap_elem.phy_cap_info[0] & he_40_mhz_cap))
> > +				return -EINVAL;
> 
> Should there be a warning message so that this is noticed if it ever
> happens? I don't know.

Yeah I don't really know either. I've done that a lot in the past, but
these days I'm kind of thinking that people who develop their drivers
should have some debug story and be able to figure it out? You know
better perhaps ...

Though it'd kind of suck to indent this further with WARN_ON ;-)

johannes
Ben Greear Jan. 12, 2024, 7:58 p.m. UTC | #5 
On 1/12/24 10:42, Johannes Berg wrote:
> On Fri, 2024-01-12 at 15:10 +0200, Kalle Valo wrote:
>> Miri Korenblit <miriam.rachel.korenblit@intel.com> writes:
>>
>>> +			/* currently no support for HE client where HT has 40 MHz but not HT */
>>> +			if (iftd->he_cap.has_he &&
>>> +			    iftd->types_mask & (BIT(NL80211_IFTYPE_STATION) |
>>> +						BIT(NL80211_IFTYPE_P2P_CLIENT)) &&
>>> +			    sband->ht_cap.ht_supported &&
>>> +			    sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40 &&
>>> +			    !(iftd->he_cap.he_cap_elem.phy_cap_info[0] & he_40_mhz_cap))
>>> +				return -EINVAL;
>>
>> Should there be a warning message so that this is noticed if it ever
>> happens? I don't know.
> 
> Yeah I don't really know either. I've done that a lot in the past, but
> these days I'm kind of thinking that people who develop their drivers
> should have some debug story and be able to figure it out? You know
> better perhaps ...
> 
> Though it'd kind of suck to indent this further with WARN_ON ;-)
> 
> johannes

I tried backporting this patch into my 6.7 tree.  An mtk7915 radio system blows up badly
in this case.  Likely this is mt76 bug, but also...it used to work and the crash doesn't
make it very obvious that the above code is to blame.

So, I suggest making this a WARN_ON with appropriate debugging output, let that get some
testing, and then when drivers are fixed, maybe add in the 'return -EINVAL'.


mt7915e 0000:06:00.0: mt7915_register_device failed, ret: -22
mt7915e 0000:06:00.0: mt7915_pci_probe had error on try 3/3, ret: -22
stack segment: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 35 Comm: ksoftirqd/3 Tainted: G        WC         6.7.0+ #31
Hardware name: Broachlink NOAH V2 E3845/Aptio CRB, BIOS 5.6.10 08/19/2021
RIP: 0010:tasklet_action_common.constprop.0+0x80/0x220
Code: 00 00 00 00 49 8b 44 24 08 48 89 18 49 89 5c 24 08 66 90 65 66 44 09 35 9e a6 ea 7e fb 0f 1f 44 00 00 48 85 ed 74 53 48 89 eb <48> 8b 6d 000
RSP: 0018:ffffc90000153e50 EFLAGS: 00010202
RAX: ffff8881283271a8 RBX: 005fff800002012c RCX: 0000000000000006
RDX: ffffffff82606ad0 RSI: 0000000000000006 RDI: ffffea0004435488
RBP: 005fff800002012c R08: 0000000000000002 R09: 0000000080000100
R10: ffffffff826060c0 R11: 000000000002e000 R12: ffff88813bd9c230
R13: ffffea0004435488 R14: 0000000000000040 R15: 0000000000000006
FS:  0000000000000000(0000) GS:ffff88813bd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000565149684ff4 CR3: 000000012176b000 CR4: 00000000001006f0
Call Trace:
  <TASK>
  ? die+0x2d/0x80
  ? do_trap+0xcd/0xf0
  ? do_error_trap+0x65/0x80
  ? exc_stack_segment+0x33/0x50
  ? asm_exc_stack_segment+0x22/0x30
  ? tasklet_action_common.constprop.0+0x80/0x220
  __do_softirq+0xb4/0x293
  ? sort_range+0x20/0x20
  run_ksoftirqd+0x1f/0x30
  smpboot_thread_fn+0xc2/0x1a0
  kthread+0xdc/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x28/0x40
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork_asm+0x11/0x20
  </TASK>
Modules linked in: qrtr ofpart spi_nor mtd intel_rapl_msr at24 spi_intel_platform regmap_i2c spi_intel iTCO_wdt intel_pmc_bxt iTCO_vendor_supports
---[ end trace 0000000000000000 ]---

Thanks,
Ben
Kalle Valo Jan. 13, 2024, 6:54 a.m. UTC | #6 
Johannes Berg <johannes@sipsolutions.net> writes:

> On Fri, 2024-01-12 at 15:10 +0200, Kalle Valo wrote:
>> Miri Korenblit <miriam.rachel.korenblit@intel.com> writes:
>> 
>> > +			/* currently no support for HE client where HT has 40 MHz but not HT */
>> > +			if (iftd->he_cap.has_he &&
>> > +			    iftd->types_mask & (BIT(NL80211_IFTYPE_STATION) |
>> > +						BIT(NL80211_IFTYPE_P2P_CLIENT)) &&
>> > +			    sband->ht_cap.ht_supported &&
>> > +			    sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40 &&
>> > +			    !(iftd->he_cap.he_cap_elem.phy_cap_info[0] & he_40_mhz_cap))
>> > +				return -EINVAL;
>> 
>> Should there be a warning message so that this is noticed if it ever
>> happens? I don't know.
>
> Yeah I don't really know either. I've done that a lot in the past, but
> these days I'm kind of thinking that people who develop their drivers
> should have some debug story and be able to figure it out? You know
> better perhaps ...

My worry here is the time needed to figure this all out. Especially if
we have more of these kind silent checks it could get complex quite
quick.

> Though it'd kind of suck to indent this further with WARN_ON ;-)

Yeah, WARN_ON() feels a bit too much. I was more thinking about a small
pr_err() or something like that which give at least some hint what's
happening.
Johannes Berg Jan. 15, 2024, 10 p.m. UTC | #7 
On Fri, 2024-01-12 at 11:58 -0800, Ben Greear wrote:
> 
> I tried backporting this patch into my 6.7 tree.  An mtk7915 radio system blows up badly
> in this case.  Likely this is mt76 bug, but also...it used to work and the crash doesn't
> make it very obvious that the above code is to blame.

Yeah, hence my comment about kernel developers hopefully being able to
figure it out :-)

> mt7915e 0000:06:00.0: mt7915_register_device failed, ret: -22
> mt7915e 0000:06:00.0: mt7915_pci_probe had error on try 3/3, ret: -22

Felix says this kind of retry logic doesn't exist upstream, maybe you
have some delta in your tree that's making it crash?

Also, from what he says and looking at the code, it should register with
HE 40 MHz capability set whenever has_he==true, so also here, do you
have any non-upstream changes that could affect it?

johannes
Ben Greear Jan. 15, 2024, 11:14 p.m. UTC | #8 
On 1/15/24 14:00, Johannes Berg wrote:
> On Fri, 2024-01-12 at 11:58 -0800, Ben Greear wrote:
>>
>> I tried backporting this patch into my 6.7 tree.  An mtk7915 radio system blows up badly
>> in this case.  Likely this is mt76 bug, but also...it used to work and the crash doesn't
>> make it very obvious that the above code is to blame.
> 
> Yeah, hence my comment about kernel developers hopefully being able to
> figure it out :-)
> 
>> mt7915e 0000:06:00.0: mt7915_register_device failed, ret: -22
>> mt7915e 0000:06:00.0: mt7915_pci_probe had error on try 3/3, ret: -22
> 
> Felix says this kind of retry logic doesn't exist upstream, maybe you
> have some delta in your tree that's making it crash?
> 
> Also, from what he says and looking at the code, it should register with
> HE 40 MHz capability set whenever has_he==true, so also here, do you
> have any non-upstream changes that could affect it?

Yes, I do.  Don't think I have anything that adjusts the 40Mhz, but possible.

Anyway, I know how to fix/work around it now, so if it works for Felix
then fine with me.

I still think you should have a pr_err or warn_on_once though, since if that clause
hits, at best case the radio suddenly became un-available.

Thanks,
Ben