-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
warn_bad_map on 5.12.0 #196
Comments
Here is some nstat from the box.
|
Hi, Thank you for the report.
That patch entered DaveM '-net' tree and should land into vanilla soon (actually is quite strange it's taking so much, but that is a completely different problem ;)
whoops, looks like warn_bad_map() dumps the wrong info in one case, I'll send a patch. Anyhow the bug looks real. We have a problem with tcp_add_backlog() which could cause the above. I'll send a patch, but I guess will be difficult to validate.
[likely unrelated] this counter is very high, I guess it's time to fix for good #177 ... |
Hi Paolo.
Yeah, I've been following it's fate, after the networking pull request gets through -- I'll move to corresponding 5.13-rcX from
Thank you! I'm almost there with setting the thing up as a default gateway, so I'll stumble upon it sooner or later.
I've been using fq_codel+bbr lately, + one of the links is really lossy at times. Maybe I'll also try out the BBRv2 patch. |
uhmmm... looks I was fooled. It seems that tcp_add_backlog() is safe. I think the splat could be cause by legit traffic, when the peer falls back to TCP - we don't send infinite mapping - and the first plain TCP packet is coalesced by the TCP stack into the previous one carrying the DSS. Even this is quite hard to test. Possibly the right thing to to is convert the WARN_ONCE into a pr_warn() |
I've captured some splats -- on the client side this time. With
|
And here are the counters from the client box.
|
The client box got stuck on me this morning, same boot as above. But I came prepared, here is dmesg (direct continuation from the [167849.044884] mark above).
|
Hello,
Oh, this looks like an unrelated (meaning: different root cause) issue. Even if the bugged code is likely triggered by the warn bad_map above. I'll file a different issue to track the problems independently.
You can drop this one, should not help. Instead you can try pulling into your tree: commit dea2b1e
from Dave'm -net tree That should not avoid the splat, but avoid unneeded subflow reset on bad mapping events, which in turn should avoid the experienced connections hang. |
see #199 |
this should be addressed by the upstream commit: commit 61e7102
|
A proxy (shadowsocks ss-server) vps running 5.12.0 + patch from #178 (
mptcp: fix data stream corruption
) got the following splat after two weeks of uptime, inconsistent use and experimentation.The text was updated successfully, but these errors were encountered: