Summary: the received window scale option was stored into SND_SCALE, which
the connection setup code then immediately overwrote with zero, so every
peer window was interpreted unscaled.
Details:
RFC 1323 negotiation is completed in two places -- the SYN_RECEIVED branch
and the active-open branch of tcp_input. Both do
mov ax, word[ebx + TCP_SOCKET.requested_s_scale]
mov word[ebx + TCP_SOCKET.SND_SCALE], ax
relying on the declared order of the four adjacent bytes SND_SCALE,
RCV_SCALE, requested_s_scale, request_r_scale to move both factors at once.
requested_s_scale, however, was never filled in: the option parser wrote the
peer's shift count into SND_SCALE directly, and that value was then clobbered
by the word move with the zero left in requested_s_scale by socket_alloc.
The result was that SND_SCALE ended up 0 on every connection while
TF_RCVD_SCALE was set, so a peer advertising, say, 64 KiB with a shift of 7
was read as advertising 512 bytes. Sending to any modern host was throttled
to a fraction of the real window.
The parser now stores into requested_s_scale, where the setup code expects
it, and clamps the value to TCP_max_winshift (14) as required by RFC 1323 --
a peer sending a larger shift must not be allowed to make our SND_WND
computation shift out of range.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reviewed-on: #619
Reviewed-by: hidnplayr <hidnplayr@gmail.com>
Reviewed-by: Mikhail Frolov <mixa.frolov2003@gmail.com>
Co-authored-by: leency <lipatov.kiril@gmail.com>
- Add `bbench` to IMG and System Panel
- Universal benchmark with 17 tests for CPU, graphics, memory and disk
- Tests can be toggled and configured
- Generates derailed reports in HTML
- Remove `MGB` and `FSPEED` from System Panel, move them from IMG to ISO
---------
Co-authored-by: Burer <burer@kolibrios.org>
Reviewed-on: #561
Reviewed-by: bad_Dr3dd0x <1702+bad_dr3dd0x@noreply.localhost>
Reviewed-by: Burer <burer@kolibrios.org>
Co-authored-by: leency <lipatov.kiril@gmail.com>
For chunked responses HTTP_receive added the whole buffer tail to
content_received every time it consumed a chunkline. When several
chunks arrived in one TCP segment, the same bytes were counted once
per chunkline (observed: content_received = 42 MB for an 83 KB page);
the value only became exact at got_all_data. A client trusting the
counter mid-transfer read far past the buffer and page-faulted.
In plain buffered mode recompute the exact value from the pointers
instead: min(chunk_ptr, write_ptr) - content_ptr, the same formula
.got_all_data_chunked uses. Data below chunk_ptr is decoded and
contiguous; bytes in [chunk_ptr, write_ptr) are still raw (unconsumed
chunkline + partial chunk). Stream/ring modes keep the running add:
there data is consumed as it arrives, so the incremental count is
correct.
---------
Co-authored-by: Burer <burer@kolibrios.org>
Reviewed-on: #569
Reviewed-by: hidnplayr <hidnplayr@gmail.com>
Reviewed-by: Burer <burer@kolibrios.org>
Co-authored-by: leency <lipatov.kiril@gmail.com>
Implemented reading filesystems with 64 bit feature for partitions < 16TB (for standard 4kb block size)
Reading support for all ext4 filesystems built with default features.
Mount filesystems with metadata_csum / metadata_csum_seed and check csum, in case it doesn't match the mount fails.
Reviewed-on: #506
Reviewed-by: Ivan B <1+dunkaist@noreply.localhost>
Reviewed-by: Mikhail Frolov <mixa.frolov2003@gmail.com>
Co-authored-by: Matou <mathieubotros@gmail.com>
I wrote an autotest for Netsurf. After 130 test run the system could not
create any new process anymore. Now this is fixed. Result:
916 OK, 0 CRASH, 0 HANG
Futexes (sysfn 77) live in the per-process handle table (PROC.htab)
and are allocated from the kernel's small-object heap via
create_object. The only code path that ever frees one is
destroy_object, which runs solely on an explicit FUTEX_DESTROY call --
and real programs never make it: newlib-based applications create a
dozen or so futexes at startup for their internal locks (malloc,
stdio) and simply exit, expecting the kernel to clean up. Nothing
does: destroy_process tears down HDLLs and page tables but never
walks the handle table.
Each leaked futex pins 48 bytes of the kernel malloc arena, and that
arena is a single fixed 128 KB block (init_malloc has no grow path).
After roughly two thousand leaked handles -- a few hundred to a few
thousand application launches within one uptime -- kernel malloc()
starts failing system-wide. The first visible casualty is
load_library: it can no longer allocate a DLLDESCR, so every dll.obj
load in every new process fails from that point on ("cannot load
library"), which is easy to mistake for a userland problem.
Reproduced by repeatedly launching a newlib application: the arena
filled with ~1750 48-byte chunks carrying the 'FUTX' magic (confirmed
by dumping the live arena; mst.topsize had dropped to 32 bytes with
free physical memory and kernel heap space still abundant), and dll
loading died after ~130 launches.
Fix: in destroy_process, after destroy_all_hdlls, walk the process's
handle table and free every live object. Free slots hold small
free-list indices and the reserved stdin/stdout/stderr handles hold
small values, so a bounds check against OS_BASE skips them; live
slots hold kernel pointers and are additionally verified by the
'FUTX' magic. If other object kinds are ever added to the handle
table, they will need their own destructors here -- the magic check
makes this walk skip them safely rather than crash.
---------
Co-authored-by: Burer <burer@kolibrios.org>
Reviewed-on: #567
Reviewed-by: hidnplayr <hidnplayr@gmail.com>
Reviewed-by: Burer <burer@kolibrios.org>
Co-authored-by: leency <lipatov.kiril@gmail.com>
Co-committed-by: leency <lipatov.kiril@gmail.com>
I wrote an autotest that runs Netsurf a lot of times. While running this
test I always faced the hang issue. First thought was about network
and sockets but QEMU debug through telnet revealed the issue in timers.
Now there is no hang after this fix.
timer_hs and cancel_timer_hs hold the global timer-list lock
(lock_timer_list/unlock_timer_list) across a short critical section
of plain list-pointer stores, without disabling interrupts. If the
owning thread is preempted inside that window, it can never be
scheduled again while a higher-priority thread is runnable: the
scheduler is strictly priority-based and osloop's check_timers (top
priority) busy-waits for the same lock via change_task, which never
descends to a lower-priority ring while its own ring has a runnable
thread. The result is a permanent, whole-system livelock -- not a
one-off race, but a deterministic outcome whenever the preemption
lands inside the section.
Reproduced by driving thousands of blocking TCP connects (each one
calls timer_hs for its connect timeout) through a browser under QEMU,
where interrupts tend to land on translation-block boundaries right
after the lock's cmpxchg. Confirmed via the QEMU monitor: osloop
spinning forever in lock_timer_list while the lock owner sat, fully
preempted, one instruction into timer_hs's critical section.
Fix: wrap the lock/insert-or-remove/unlock sequence in
timer_hs and cancel_timer_hs with pushfd/cli ... popfd, making it
atomic with respect to preemption. The wait loop inside
lock_timer_list is unaffected -- change_task manages IF on its own,
so spinning there with interrupts off cannot itself hang anything.
Reviewed-on: #564
Reviewed-by: Ivan B <1+dunkaist@noreply.localhost>
Reviewed-by: hidnplayr <hidnplayr@gmail.com>
Co-authored-by: Kiril Lipatov <lipatov.kiril@gmail.com>
Co-committed-by: Kiril Lipatov <lipatov.kiril@gmail.com>
- add real `mkdir()` (`sys/mkdir.c`) that strips a trailing `/` rejected by the `_ksys_mkdir`
- add real `rmdir()` (`sys/rmdir.c`) wrapping `_ksys_rmdir`
- define `NAME_MAX` in `<limits.h>`
Reviewed-on: #545
Reviewed-by: Егор Ярин <y.yarin@inbox.ru>
Reviewed-by: Ivan B <1+dunkaist@noreply.localhost>
- set folder attribute (0x10) for get-info on / and on devices
- split root get-info (subfn 5) from read-folder (subfn 1)
- zero the full BDFE header so timestamps/size aren't leftover garbage
Reviewed-on: #544
Reviewed-by: Ivan B <1+dunkaist@noreply.localhost>
Reviewed-by: Mikhail Frolov <mixa.frolov2003@gmail.com>
- use framebuffer to prevent flickering
- unify all code to snake_case
- optimize data to fit into 5*512 bytes (thanks to @Leency)
Reviewed-on: #533
Reviewed-by: Kiril Lipatov <lipatov.kiril@gmail.com>
Reviewed-by: Mikhail Frolov <mixa.frolov2003@gmail.com>
FASM launcher that starts wolf3d/doom/quake with the chosen window size and
mode via CLI args. Wire it into autobuild and the games menu; doom is now
built from source, so drop the prebuilt binary.
- grow the heap to fit the z-buffer and surface cache for the requested
resolution
- clamp -winsize to MAXWIDTH x MAXHEIGHT so a large window cannot overrun
the software renderer''s static tables
- render the fixed 320x200 frame to a 24bpp surface and SoftStretch it to
an arbitrary window size (-winsize); drop the old blocky integer scaler
- fix sfx: take the slice size from the obtained SDL audio spec
- set CWD to the executable dir so the WAD is found when run from launcher
- read config from DOOMRC.TXT next to the WAD
- add to autobuild
- use bufferPitch instead of screenWidth for the view offset on
non-standard window sizes
- default to windowed and honor --windowed/--fullscreen so the launcher
controls the mode (the SDL backend now acts on SDL_FULLSCREEN, which
used to be ignored)
- center the logical 320x200 layer (menus, title/intro, fonts, fullscreen
pics) when the resolution is not an exact multiple of 320x200; the 3D
view and in-game HUD stay full-screen
LeencyandClaude Opus 5
b00bl1k
Burer
Matou1306
DoczomandBurer
Egor00f