Page MenuHomeFreeBSD

Rack crash that Larry Rosenman found..
ClosedPublic

Authored by rrs on Jun 11 2018, 12:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 7:28 AM
Unknown Object (File)
Nov 10 2023, 2:39 AM
Unknown Object (File)
Nov 8 2023, 2:28 AM
Unknown Object (File)
Nov 6 2023, 11:49 PM
Unknown Object (File)
Oct 7 2023, 1:24 AM
Unknown Object (File)
Oct 5 2023, 10:48 PM
Unknown Object (File)
Sep 17 2023, 1:46 AM
Unknown Object (File)
Jul 3 2023, 5:36 AM

Details

Summary

Turns out Rack is not fully TFO capable (which we knew).. it branched before
TFO settled into the tree. Now this set of changes updates rack's TFO handling
to match the default stack. It may not be 100% right but hopefully no more crashes
will occur ;)

What this does is

  1. Bring in updates from tcp_input/output to rack that were done and missed in rack.
  2. Change some of those to understand the "rack-isms" on how rack does things so that we won't for example calculate a -1 offset in the socket buffer.
Test Plan

I have handed Larry a patch to re-test to see if it resolves his issue. Besides
the review I will wait for FeedBack from Larry on this.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

ler added a subscriber: ler.

I've got this and D15757 running since:
system boot Jun 11 08:24

We'll see

This passes my "sniff test", but it would be better to get @pkelsey to review it.

So this is weird we look like we sent a TFO and then hit a retransmit.. but somehow
the TFO flags was removed so we did not set len == 0 on having a SYN retransmitted.

Now that should just not be.. so I will now add a safety that checks for
Non_TFO and SYN .. and if its true it will zap len to 0.

This may not fly with TFO itself but I don't see how it hurts since if
we are not doing TFO you should never send a SYN with data.

Turns out after looking at Larry's last core and contemplating it a bit if it
would have succeeded (which it did not) we would have crashed anyway.
This is because the SYN got included in the send_map and we would have
tried to trim 14 instead of the 13 that bytes in the socketbuffer. Fixing that
means the send_map cannot start at snd_una for the TFO case. This means
a bit more special code needs also to be added to the SYN_SENT case then
so you end up incrementing snd_una when you move to established and that
way when you call the ack processing code all will be well :)

New kernel with this running since:
system boot Jun 12 10:28

(US/CDT, UTC-5).

This revision was not accepted when it landed; it landed in state Needs Review.Jun 14 2018, 3:27 AM
This revision was automatically updated to reflect the committed changes.