Re: Status of 802.11s in wireless-testing?

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

Hi Javier,

> I agree that there is a bug in that would cause a synchronize_rcu() in
> an atomic section when the mpath table grows beyond a certain size.
> The bug was there since the first submission of the mesh code, yes.
> 
> However, the "bunch of bugs that appear to have been in the code
> forever" are, I believe, regressions.  In particular we've identified:
>  - Airtime Link Metric broken (fix in progress)
>  - Forwarding path broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124698982910794&w=2)
>  - mpath pending queue broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124717648406661&w=2)
>  - PREQ notification broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124752948320455&w=2)
> 
> We've been busy with those but the synchronize_rcu fix is next in our list.

I was really only referring to the issue with synchronize_rcu(), and the
two related things where there's GFP_KERNEL that should be GFP_ATOMIC,
although that might have been fixed? It just felt like multiple
issues/places to me that could run into this.

> I also agree with your assessment of the severity of the bug.
> Hopefully we'll get to fix it really soon so we can re-enable mesh
> again.

Yes, that would be great, thanks. I've been meaning to look into this
(if only to understand the mesh code better), but I have little time and
a lot of other things to fix that are still regressions (currently
looking at assoc vs. reassoc for instance).

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]