Repository navigation
sysupgrade: install an archive from /tmp on an 18 MB XM510 - #2649
Merged
Merged
Conversation
No archive could be installed on an XM510 at its stock mem=18M -- the WebUI's "install from a file" included (#2618). Three things stood in the way, and each is fixed here: - The RAM guards never ran. usable_ram() read only MemAvailable, which kernels before 3.14 do not report (XM510 3.0, XM530 3.10, hi3516cv100 3.0.8). It now estimates it there, with the arithmetic si_mem_available() uses, so check_unpack_ram and check_flash_ram -- and the majestic stop they fall back on -- work on those kernels too. - /tmp's cap refused it. A tmpfs defaults to half of RAM, 7804 KB here, against the 8341 KB an archive and its images take together, though the RAM behind it had room. When the cap is all that is short and RAM was measured to hold the unpack, grow_tmp() raises it for the run; a run that stays up gets the old cap back. - majestic was OOM-killed entering upgrade mode. With the 4 MB archive in a tmpfs nothing can reclaim, a majestic started a minute earlier faulted its pages back after drop_caches during prepare and was killed, and the run died with it, leaving the lock and no majestic. An archive in /tmp that will not unpack beside majestic now has it stopped up front, as check_unpack_ram would stop it later anyway, instead of asked to prepare.
widgetii
requested review from
cronyx,
flyrouter and
viktorxda
as code owners
October 21, 2026 06:33
PR Summary by QodoAllow sysupgrade archives in /tmp on low-memory cameras
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
Review of the archive change: - The early stop ran before the watchdog owner was recorded, so a majestic that held the watchdog went unrecorded and the RAM-phase keeper never armed. The owner is now recorded first. Stopping an owning majestic there is allowed: its own stop gives the device back with the magic close, and where a driver ignores that, the recorded ownership arms the keeper from the pivot on. - A stop that was refused or failed skipped prepare and its legacy fallback altogether. It now falls back to them. - On a --no_reboot exit the unpacked images stayed in /tmp, so a cap raised for them could not be put back. They are discarded first, as die() does.
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
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.
Problem
Closes #2618. On an XM510 at its stock
mem=18M, no archive staged in/tmpcould be installed, which includes the WebUI's "install from a file". Confirmed on a lab XM510 + JX-H62, not only under emulation:Fixing that refusal exposed two more problems on the same board.
Change
The RAM guards never ran on this kernel.
usable_ram()read onlyMemAvailable, which kernels before 3.14 don't report (XM510 3.0, XM530 3.10, hi3516cv100 3.0.8), and on those kernels it gave no opinion. It now estimates the figure with the same arithmetic assi_mem_available():min_free_kbytesplus a quarter);check_unpack_ram,check_flash_ramand their majestic stop now work on those kernels. On the lab XM510's real/proc/meminfothe estimate gives 8,302 KB; that figure is pinned in a test./tmp's cap refused what RAM could hold. A tmpfs defaults to half of RAM, 7,804 KB here, against 8,341 KB for an archive plus its images. A cap is a ceiling on pages as they're written, not memory set aside. When the cap is all that is short and RAM was measured to hold the unpack,grow_tmp()remounts/tmpwith a largersize=for this run. A run that stays up gets the old cap back. With no RAM figure, or on a ramfs, the refusal stands.majestic was OOM-killed entering upgrade mode. On a freshly booted XM510 with the 4 MB archive in
/tmp,majestic_api preparetipped the board over. Afterdrop_caches, majestic faulted its pages back with nothing left to reclaim (548 KB free, 40 KB of file cache, 4,264 KB of tmpfs), and the kernel killed it. The run died with it, leaving/tmp/sysupgrade.lockand a camera with no majestic until rebooted. Reproduced twice, traced to thatcurl. An archive in/tmpthat won't unpack beside majestic now has majestic stopped up front, sincecheck_unpack_ramwould stop it later anyway, instead of being asked to prepare. With room, majestic still prepares as before.This builds on #2648 (PID 1 hand-off), which is what makes the rootfs write itself safe on this board.
Hardware tested on
XM510 + JX-H62,
xm510_litefrom firmware master (kernel 3.0.101,mem=18M, 15.6 MBMemTotal). This branch'ssysupgrade, comment-stripped as the build ships it, was installed in the overlay for the test and removed afterwards.Evidence
Before, with the image's own sysupgrade:
With only fixes 1 and 2, on a freshly booted camera:
After, with all three fixes:
sysupgrade -z --archive=/tmp/openipc.xm510-nor-lite.tgz, three runs, each starting about a minute after the previous reboot (a fresh majestic, the case that OOMed):After each reboot
/tmpis back to its 7,804 KB cap.Not tested: the WebUI upload itself (
--web). On that path majestic has already entered upgrade mode before sysupgrade runs, so fix 3 doesn't apply; fixes 1 and 2 do.Tests:
test_sysupgrade.sh: 328 checks pass. New or changed:/tmpwith no RAM figure is still refused;/tmpshort only by its cap is raised when RAM backs it;MemAvailableestimated assi_mem_available()(8,302 KB from the XM510's meminfo);STRICT=1 test_shell_parse.shandtest_strip_shell_comments.sh: clean.Scope
general/package/all-patches/linux/(those go to OpenIPC/linux)general/overlay/or in a sharedload_<vendor>script hardcodes a value specific to my boardLD_PRELOAD, and no binaries that cannot be rebuilt from source