Compare commits

...
Author SHA1 Message Date
Leency 4f181f1718 kernel/net: recheck the ARP entry after sleeping for a reply
Check kernel codestyle / Check kernel codestyle (pull_request) Successful in 23s
Test PR / Build (en_US) (pull_request) Successful in 2m47s
Test PR / Build (es_ES) (pull_request) Successful in 2m59s
Test PR / Build (ru_RU) (pull_request) Successful in 3m19s
arp_del_entry compacts the table, so the entry could move while an app
waited and esi then pointed at another IP's entry - a valid one sent the
packet to the wrong MAC. Look the IP up again when it no longer matches.
2026-09-30 10:14:27 +03:00
Leency 9c7ddc8221 kernel/net: never busy-wait for an ARP reply in a kernel thread
arp_ip_to_mac spun in delay_ms until the ARP request timed out. The
kernel's network threads (TCP input, TCP timers, ethernet input) and the
OS task run at MAX_PRIORITY, so while one of them spun here no
application was scheduled at all: on a tester's laptop the desktop and
zeroconf froze for the full 20 s ARP timeout every time a TCP segment
went out on an interface that had just lost its address.

A kernel thread now gives up at once (TCP retransmits the segment). An
application thread sleeps in 10 ms steps for at most ARP_WAIT_TICKS
(1 s) and then gives up as well; the reply arrives through the ethernet
input thread, which keeps running meanwhile.
2026-09-30 10:14:26 +03:00
+47 -7
View File
@@ -23,6 +23,7 @@ ARP_AWAITING_RESPONSE = 2
ARP_RESPONSE_TIMEOUT = 3
ARP_REQUEST_TTL = 31 ; 20 s
ARP_WAIT_TICKS = 100 ; 1 s
ARP_ENTRY_TTL = 937 ; 600 s
ARP_STATIC_ENTRY = -1
@@ -565,10 +566,10 @@ arp_ip_to_mac:
; Now send a request packet on the network
pop edi eax ; IP in eax, device number in ebx, for ARP_output_request
push esi edi
push eax esi edi ; arp_output_request trashes eax
mov ebx, [net_device_list + edi]
call arp_output_request
pop edi esi
pop edi esi eax
.found_it:
cmp [esi + ARP_entry.Status], ARP_VALID_MAPPING ; Does it have a MAC assigned?
je .valid
@@ -577,11 +578,50 @@ if ARP_BLOCK
cmp [esi + ARP_entry.Status], ARP_AWAITING_RESPONSE ; Are we waiting for reply from remote end?
jne .give_up
push esi
mov esi, 10 ; wait 10 ms
call delay_ms
pop esi
jmp .found_it ; now check again
; Only applications may wait for the reply, kernel threads give up at once
push ecx edx
mov edx, [current_slot]
cmp [edx + APPDATA.priority], MAX_PRIORITY
je .wait_over
mov edx, [timer_ticks]
add edx, ARP_WAIT_TICKS
.wait:
push ebx
mov ebx, 1 ; sleep 10 ms
call delay_hs
pop ebx
; The entry may have moved (arp_del_entry), find it again
cmp [esi + ARP_entry.IP], eax
je .same_entry
mov ecx, [ARP_entries + edi]
test ecx, ecx
jz .wait_over
mov esi, edi
imul esi, (sizeof.ARP_entry * ARP_TABLE_SIZE)/4
add esi, ARP_table + ARP_entry.IP
.rescan:
cmp [esi], eax
je .same_entry
add esi, sizeof.ARP_entry
dec ecx
jnz .rescan
jmp .wait_over
.same_entry:
cmp [esi + ARP_entry.Status], ARP_VALID_MAPPING
je .wait_done
cmp [esi + ARP_entry.Status], ARP_AWAITING_RESPONSE
jne .wait_over
mov ecx, [timer_ticks]
sub ecx, edx
js .wait
.wait_over:
pop edx ecx
jmp .give_up
.wait_done:
pop edx ecx
else