fix: dynamically calculate max_pages based on system page size#189
Merged
stapelberg merged 1 commit intojacobsa:masterfrom Mar 2, 2026
Merged
fix: dynamically calculate max_pages based on system page size#189stapelberg merged 1 commit intojacobsa:masterfrom
stapelberg merged 1 commit intojacobsa:masterfrom
Conversation
kislaykishore
force-pushed
the
master
branch
from
c64a2b6 to
90702b4
Compare
kislaykishore
changed the title
kislaykishore
force-pushed
the
master
branch
from
90702b4 to
7885875
Compare
geertj
reviewed
Feb 26, 2026
geertj
reviewed
Feb 26, 2026
geertj
approved these changes
Feb 26, 2026
kislaykishore
force-pushed
the
master
branch
3 times, most recently
from
570c3e1 to
247e587
Compare
Contributor
Author
|
@geertj @mustvicky I've now enhanced the logging as well so that it's easier to identify these errors in the future. |
geertj
reviewed
Feb 27, 2026
geertj
reviewed
Feb 27, 2026
kislaykishore
force-pushed
the
master
branch
from
247e587 to
bacf561
Compare
stapelberg
reviewed
Mar 2, 2026
Hardcoding FUSE `max_pages` to 256 assumes a 4KiB page size yielding a 1MiB max request. On ARM64 architectures (e.g., Grace CPU) with 64KiB pages, 256 pages allows the kernel to send read-ahead requests up to 16MiB. This overflows the daemon's fixed 1MiB buffer pool, resulting in 0-byte reads, premature EOFs, and fatal SIGBUS errors in mmap-heavy applications like TensorRT. This fix dynamically calculates the limit during the FUSE INIT phase: max_pages = (1 MiB buffer capacity) / os.Getpagesize() On 64KiB systems, this safely caps `max_pages` at 16. The kernel will now strictly split large read-ahead demands into 1MiB chunks, preventing buffer overflows and crashes.
stapelberg
approved these changes
Mar 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hardcoding FUSE
max_pagesto 256 assumes a 4KiB page size yielding a 1MiB max request. On ARM64 architectures (e.g., Grace CPU) with 64KiB pages, 256 pages allows the kernel to send read-ahead requests up to 16MiB.This overflows the daemon's fixed 1MiB buffer pool, resulting in 0-byte reads, premature EOFs, and fatal SIGBUS errors in mmap-heavy applications like TensorRT.
This fix dynamically calculates the limit during the FUSE INIT phase:
max_pages = (1 MiB buffer capacity) / os.Getpagesize()On 64KiB systems, this safely caps
max_pagesat 16. The kernel will now strictly split large read-ahead demands into 1MiB chunks, preventing buffer overflows and crashes.