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:
signature.asc
Description: This is a digitally signed message part
