eburet-oss/gvisor-lx
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

snapshot: sagernet/gvisor v0.0.0-20260727.0-sing-box-mod.1 + SPEC 048 guard

Browse source 
Обновление снапшота с v0.0.0-20250811.0 на пин, которого требует
sing-box после мержа 235 коммитов (upstream d620bbbf2 "Update gvisor to
20260727.0"). Прежний снапшот был взят 2026-08-04 ровно с той версии,
на которой тогда стоял апстрим; разрыв возник 2026-08-05 вместе с его
бампом.

За год апстрим-gvisor изменил ~14 000 строк в 292 файлах. Значимое для
нас — сетевой стек: tcp/connect.go (PMTU-discovery + исправление
начального RTT/RTO: раньше задержка ACK внутри стека завышала стартовый
таймаут на несколько RTT), tcp/snd.go, tcp/rcv.go, stack/conntrack.go,
stack/packet_buffer.go. Всего 30 файлов в TCP и 37 в stack.

Баг SPEC 048 апстрим НЕ исправил — проверено по коду новой версии:
handleConnecting по-прежнему проверяет состояние endpoint'а, но не ep.h,
а performHandshake так же зануляет h и отпускает мьютекс до Close().
Поэтому guard перенесён (12 строк) вместе со своим тестом (45 строк).

Red/green проверен на новой базе: без guard'а тест падает с той же
nil-паникой, что в полевом крашдампе; с ним зелёный.
This commit is contained in:
Leadaxe 2026-08-05 14:53:31 +03:00
parent ffebe42860
commit 117243aa02
293 changed files with 16413 additions and 2842 deletions
Download patch file Download diff file Expand all files Collapse all files

22
pkg/tcpip/transport/tcp/rack.go
View file

@ -78,7 +78,15 @@ func (rc *rackControl) init(snd *sender, iss seqnum.Value) {
// update will update the RACK related fields when an ACK has been received.
// See: https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-6.2
func (rc *rackControl) update(seg *segment, ackSeg *segment) {
rtt := rc.snd.ep.stack.Clock().NowMonotonic().Sub(seg.xmitTime)
// Compute the RTT sample against the time the ACK was received at ingress
// (ackSeg.rcvdTime), not the current clock. The two differ when the ACK was
// delayed inside the stack before being processed (e.g. it sat in the
// endpoint's segment queue while the application held the endpoint lock
// during a Write that synchronously flushed a window). Using the processing
// time would inflate the RTT by that internal delay, corrupting RACK.RTT,
// RACK.minRTT and the reorder window, and causing spurious loss detection.
// detectLoss already uses ackSeg.rcvdTime; this keeps update consistent.
rtt := ackSeg.rcvdTime.Sub(seg.xmitTime)
// If the ACK is for a retransmitted packet, do not update if it is a
// spurious inference which is determined by below checks:
@ -400,7 +408,17 @@ func (rc *rackControl) reorderTimerExpired() tcpip.Error {
return nil
}
numLost := rc.detectLoss(rc.snd.ep.stack.Clock().NowMonotonic())
// Evaluate loss as of the time the reorder timer was scheduled to fire (its
// target), not the current clock. The timer is armed for the instant a
// segment's reorder window elapses, but the timer callback itself can run
// arbitrarily late under load (the processor goroutine is busy, or the
// endpoint lock is held while a Write flushes a window). Using the
// (possibly much later) processing time would make timeRemaining strongly
// negative and mark not-yet-lost segments as lost, triggering spurious
// retransmits and recovery on a path with little or no real loss
// (gvisor#9707/#9778). detectLoss arms the timer from rcvdTime-derived
// values, so evaluating it at the timer target keeps the two consistent.
numLost := rc.detectLoss(rc.snd.reorderTimer.target)
if numLost == 0 {
return nil
}