use /etc/clonetab to provide devices to be cloned#1
Open
src-up wants to merge 3338 commits into
Open
Conversation
src-up
pushed a commit
that referenced
this pull request
Jan 21, 2026
Otherwise, if the VM is unexpectedly rebooted, then `importctl --user pull-tar` may fail as the file may already exist. ``` [ 123.351751] TEST-13-NSPAWN.sh[3946]: + run0 -u testuser importctl --user pull-tar file:///var/tmp/image-tar/kurps.tar.gz nurps --verify=checksum -m [ 123.541603] TEST-13-NSPAWN.sh[4311]: Enqueued transfer job 3. Press C-c to continue download in background. [ 123.552456] TEST-13-NSPAWN.sh[4311]: Pulling 'file:///var/tmp/image-tar/kurps.tar.gz', saving as 'nurps'. [ 123.552788] TEST-13-NSPAWN.sh[4311]: Operating on image directory '/home/testuser/.local/state/machines'. [ 123.819942] TEST-13-NSPAWN.sh[4311]: Got 1% of file:///var/tmp/image-tar/kurps.tar.gz. [ 124.156557] TEST-13-NSPAWN.sh[4311]: * shutting down connection #0 [ 124.156896] TEST-13-NSPAWN.sh[4311]: * Could not open file /var/tmp/image-tar/kurps.tar.gz.sha256 [ 124.157223] TEST-13-NSPAWN.sh[4311]: * closing connection #-1 [ 124.159198] TEST-13-NSPAWN.sh[4311]: * Could not open file /var/tmp/image-tar/kurps.nspawn [ 124.159493] TEST-13-NSPAWN.sh[4311]: * closing connection #-1 [ 124.159818] TEST-13-NSPAWN.sh[4311]: Acquired 68.5M. [ 124.160395] TEST-13-NSPAWN.sh[4311]: Download of file:///var/tmp/image-tar/kurps.tar.gz complete. [ 124.160664] TEST-13-NSPAWN.sh[4311]: Transfer failed: Could not read a file:// file [ 124.160923] TEST-13-NSPAWN.sh[4311]: Settings file could not be retrieved, proceeding without. [ 124.404733] TEST-13-NSPAWN.sh[4311]: * shutting down connection #1 [ 124.405162] TEST-13-NSPAWN.sh[4311]: Acquired 79B. [ 124.406170] TEST-13-NSPAWN.sh[4311]: Download of file:///var/tmp/image-tar/SHA256SUMS complete. [ 124.406734] TEST-13-NSPAWN.sh[4311]: SHA256 checksum of file:///var/tmp/image-tar/kurps.tar.gz is valid. [ 124.455446] TEST-13-NSPAWN.sh[4311]: Failed to rename to final image name to /home/testuser/.local/state/machines/.tar-file:\x2f\x2f\x2fvar\x2ftmp\x2fimage-tar\x2fkurps\x2etar\x2egz: File exists [ 124.457251] TEST-13-NSPAWN.sh[4311]: Exiting. ``` Workaround for issue systemd#38240.
src-up
force-pushed
the
PR-etc-clonetab
branch
3 times, most recently
from
aff7c48 to
63e0b1d
Compare
src-up
force-pushed
the
PR-etc-clonetab
branch
3 times, most recently
from
c35a30a to
bccc71a
Compare
src-up
pushed a commit
that referenced
this pull request
Apr 9, 2026
Fix a typo which causes a segfault when processing a user record
with matchHostname when it's an array instead of a simple string:
$ echo '{"userName":"crashhostarray","perMachine":[{"matchHostname":["host1","host2"],"locked":false}]}' | userdbctl -F -
Segmentation fault (core dumped)
$ coredumpctl info
...
Message: Process 1172301 (userdbctl) of user 1000 dumped core.
Module libz.so.1 from rpm zlib-ng-2.3.3-1.fc43.x86_64
Module libcrypto.so.3 from rpm openssl-3.5.4-2.fc43.x86_64
Stack trace of thread 1172301:
#0 0x00007fded7b3a656 __strcmp_evex (libc.so.6 + 0x159656)
#1 0x00007fded7e95397 per_machine_hostname_match (libsystemd-shared-260.so + 0x295397)
systemd#2 0x00007fded7e955b5 per_machine_match (libsystemd-shared-260.so + 0x2955b5)
systemd#3 0x00007fded7e957c6 dispatch_per_machine (libsystemd-shared-260.so + 0x2957c6)
systemd#4 0x00007fded7e96c97 user_record_load (libsystemd-shared-260.so + 0x296c97)
systemd#5 0x000000000040572d display_user (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x572d)
systemd#6 0x00007fded7ea9727 dispatch_verb (libsystemd-shared-260.so + 0x2a9727)
systemd#7 0x000000000041077c run (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x1077c)
systemd#8 0x00000000004107ce main (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x107ce)
systemd#9 0x00007fded79e45b5 __libc_start_call_main (libc.so.6 + 0x35b5)
systemd#10 0x00007fded79e4668 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3668)
systemd#11 0x00000000004038d5 _start (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x38d5)
ELF object binary architecture: AMD x86-64
src-up
pushed a commit
that referenced
this pull request
Apr 9, 2026
The fido2_hmac_salt/fido2_hmac_credential/recovery_key fields kept
leaking memory as the array itself wasn't deallocated after deallocating
each of its elements data:
$ build-san/userdbctl -F fuzz-corpus-userdb/auth-fido2.json
...
=================================================================
==1292840==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 112 byte(s) in 1 object(s) allocated from:
#0 0x7f56f00e5e4b in realloc.part.0 (/lib64/libasan.so.8+0xe5e4b) (BuildId: 25975f766867e9e604dc5a71a8befeaed3301942)
#1 0x7f56ed869e42 in greedy_realloc ../src/basic/alloc-util.c:65
systemd#2 0x7f56ed7ff5e9 in dispatch_fido2_hmac_salt ../src/shared/user-record.c:836
systemd#3 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
systemd#4 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
systemd#5 0x7f56ed80100b in dispatch_privileged ../src/shared/user-record.c:998
systemd#6 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
systemd#7 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
systemd#8 0x7f56ed80622c in user_record_load ../src/shared/user-record.c:1697
systemd#9 0x000000408c15 in display_user ../src/userdb/userdbctl.c:447
systemd#10 0x7f56ed83cc9a in dispatch_verb ../src/shared/verbs.c:137
systemd#11 0x00000041df2b in run ../src/userdb/userdbctl.c:1908
systemd#12 0x00000041dfbe in main ../src/userdb/userdbctl.c:1911
systemd#13 0x7f56ec8105b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
systemd#14 0x7f56ec810667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
systemd#15 0x000000404a44 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/userdbctl+0x404a44) (BuildId: 19e8b7e7b7038d2cea20bc18a55bea2a9e4406d5)
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f56f00e5e4b in realloc.part.0 (/lib64/libasan.so.8+0xe5e4b) (BuildId: 25975f766867e9e604dc5a71a8befeaed3301942)
#1 0x7f56ed869e42 in greedy_realloc ../src/basic/alloc-util.c:65
systemd#2 0x7f56ed7fe779 in dispatch_fido2_hmac_credential_array ../src/shared/user-record.c:775
systemd#3 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
systemd#4 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
systemd#5 0x7f56ed80622c in user_record_load ../src/shared/user-record.c:1697
systemd#6 0x000000408c15 in display_user ../src/userdb/userdbctl.c:447
systemd#7 0x7f56ed83cc9a in dispatch_verb ../src/shared/verbs.c:137
systemd#8 0x00000041df2b in run ../src/userdb/userdbctl.c:1908
systemd#9 0x00000041dfbe in main ../src/userdb/userdbctl.c:1911
systemd#10 0x7f56ec8105b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
systemd#11 0x7f56ec810667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
systemd#12 0x000000404a44 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/userdbctl+0x404a44) (BuildId: 19e8b7e7b7038d2cea20bc18a55bea2a9e4406d5)
SUMMARY: AddressSanitizer: 176 byte(s) leaked in 2 allocation(s).
src-up
pushed a commit
that referenced
this pull request
Apr 9, 2026
…d#40979) Fix a typo which causes a segfault when processing a user record with `matchHostname` when it's an array instead of a simple string: ``` $ echo '{"userName":"crashhostarray","perMachine":[{"matchHostname":["host1","host2"],"locked":false}]}' | userdbctl -F - Segmentation fault (core dumped) $ coredumpctl info ... Message: Process 1172301 (userdbctl) of user 1000 dumped core. Module libz.so.1 from rpm zlib-ng-2.3.3-1.fc43.x86_64 Module libcrypto.so.3 from rpm openssl-3.5.4-2.fc43.x86_64 Stack trace of thread 1172301: #0 0x00007fded7b3a656 __strcmp_evex (libc.so.6 + 0x159656) #1 0x00007fded7e95397 per_machine_hostname_match (libsystemd-shared-260.so + 0x295397) systemd#2 0x00007fded7e955b5 per_machine_match (libsystemd-shared-260.so + 0x2955b5) systemd#3 0x00007fded7e957c6 dispatch_per_machine (libsystemd-shared-260.so + 0x2957c6) systemd#4 0x00007fded7e96c97 user_record_load (libsystemd-shared-260.so + 0x296c97) systemd#5 0x000000000040572d display_user (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x572d) systemd#6 0x00007fded7ea9727 dispatch_verb (libsystemd-shared-260.so + 0x2a9727) systemd#7 0x000000000041077c run (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x1077c) systemd#8 0x00000000004107ce main (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x107ce) systemd#9 0x00007fded79e45b5 __libc_start_call_main (libc.so.6 + 0x35b5) systemd#10 0x00007fded79e4668 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3668) systemd#11 0x00000000004038d5 _start (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x38d5) ELF object binary architecture: AMD x86-64 ```
src-up
pushed a commit
that referenced
this pull request
Apr 27, 2026
There are only a few target dirs we place resources in when generating on-the-fly initrd cpios. These dirs have very specific attributes. Instead of repeating this everywhere, let's encapsulate them in a new explicit structure, that we can reuse at various places. This is preparation for placing extra resources of Type #1 entry also in them without having to encode access modes at multiple places redundantly.
src-up
pushed a commit
that referenced
this pull request
Jun 2, 2026
On some architectures like m68k, alignof(void*) is 2, not sizeof(void*)
(which is 4). So the natural alignment of struct Option is 2 and
sizeof(Option) == 26.
However, each variable placed in the SYSTEMD_OPTIONS ELF section via
_OPTION() carries _alignptr_ (= __attribute__((aligned(sizeof(void*))))),
which forces each entry to start at a 4-byte boundary. The linker
therefore inserts 2 bytes of padding between adjacent entries, producing
an actual stride of 28 in the section.
option_parse() iterates over the section with pointer arithmetic
("opt++"), which advances by sizeof(Option) == 26 and lands inside the
padding. The fields read back as zero, and since commit cf88903
("tree-wide: get rid of most uses of ALIGN_PTR") added the ordering
assertion below, the resulting "0 < 0" trips it when running --help:
Assertion 'opt->id < (opt + 1)->id' failed at src/shared/options.c:116, function option_parse(). Aborting.
#0 0xc0a7b248 in ?? () from /usr/lib/m68k-linux-gnu/libc.so.6
#1 0xc0a7b2ce in pthread_kill () from /usr/lib/m68k-linux-gnu/libc.so.6
systemd#2 0xc0a2edc6 in raise () from /usr/lib/m68k-linux-gnu/libc.so.6
systemd#3 0xc0a1c128 in abort () from /usr/lib/m68k-linux-gnu/libc.so.6
systemd#4 0xc05c6f78 in option_parse (options=0x0, options_end=0x0, state=0xc09ca968) at ../src/shared/options.c:116
Fix this by applying _alignptr_ to the struct definition itself, so that
sizeof(Option) is padded up to a multiple of sizeof(void*) and matches
the actual on-disk stride. Add an assert_cc() so any future regression
is caught at compile time.
The same latent bug applies to Verb and TestFunc, which use the same
section-placement pattern. Their natural sizeof was already a multiple
of sizeof(void*) so no crash was observed, but apply the same fix
defensively.
Follow-up for cf88903
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
src-up
pushed a commit
that referenced
this pull request
Jun 2, 2026
sd_journal_get_data() can return a MESSAGE data object whose payload does not start with "MESSAGE=", e.g. when the journal file is corrupted. Instead of aborting the whole process, log and skip over such an entry like we do for other bad/missing fields. [ 87.287390] post.sh[1619]: + journalctl -q -o short-monotonic --grep 'didn'\''t pass validation' [ 87.287844] post.sh[1620]: + grep -v test-varlink-idl [ 87.325676] post.sh[1619]: Assertion 'message = startswith(message, "MESSAGE=")' failed at src/journal/journalctl-show.c:261, function show(). Aborting. #0 0x00007fb47b49a29c n/a (libc.so.6 + 0x9a29c) #1 0x00007fb47b43e7d0 raise (libc.so.6 + 0x3e7d0) systemd#2 0x00007fb47b425681 abort (libc.so.6 + 0x25681) systemd#3 0x00007fb47b8a1ace log_assert_failed (libsystemd-shared-261~rc2.so + 0xa1ace) systemd#4 0x000055f8e1ef9ddb show (journalctl + 0xcddb) systemd#5 0x000055f8e1efa6ee action_show (journalctl + 0xd6ee) systemd#6 0x000055f8e1ef3c20 run (journalctl + 0x6c20) systemd#7 0x00007fb47b427741 n/a (libc.so.6 + 0x27741) systemd#8 0x00007fb47b427879 __libc_start_main (libc.so.6 + 0x27879) systemd#9 0x000055f8e1ef4915 _start (journalctl + 0x7915) Co-developed-by: Claude Opus 4.8 <noreply@anthropic.com>
src-up
force-pushed
the
PR-etc-clonetab
branch
11 times, most recently
from
52ef5aa to
ba6ab28
Compare
They will be used in later commits.
This introduce OpenSSL port of fsprg, which is implemented by using libgcrypt.
…ests With this change, gcrypt dependency is not mandatory. Hence, allow to build systemd even when -D gcrypt=enabled but gcrypt devel package is not installed.
Factor a yes/no variant of prompt_loop() out into prompt-util.[ch], so the various interactive tools can share a single implementation, and convert systemd-sysinstall's installation confirmation question over to it.
Introduce an EnrollContext structure that carries everything the enrollment and unlocking helpers need, and route all enroll_*()/load_volume_key_*()/ wipe_slots() calls through it. The command line still populates the existing arg_* globals as before; once parsing is complete they are copied into a self-contained EnrollContext (which owns its strings/arrays) and the rest of the code only ever reads from the context. This is preparation for the upcoming varlinkification of systemd-cryptenroll: a Varlink dispatcher (and later an interactive first-boot wizard) can populate the very same EnrollContext without going through the arg_* parsing layer. To support non-interactive (e.g. Varlink) callers, the context carries an 'interactive' flag: when false, every credential prompt is disabled and the helpers fail with -ENOPKG (the established "querying disabled via headless" code) instead of blocking on a tty. Passwords, FIDO2 PINs and PKCS#11 PINs are all covered, and an optional FIDO2 PIN can be supplied directly via the context. enroll_recovery() additionally grows a quiet mode that returns the recovery key instead of printing it. This also adds one new field to EnrollContext which didn't exist before: the unlock_password is useful for the Varlink hookup later. No change in command line behaviour.
This is preparation for the Varlinkification, as then we want to pass the password in via IPC instead of prompting the user. Note that this only adds the field, and applies it, but never actually sets it. That's for the varlinkification later.
…ervice Add a Varlink interface for systemd-cryptenroll, building on the EnrollContext introduced previously. A single Enroll method covers password, recovery-key and FIDO2 enrollment; PKCS#11 and TPM2 are not exposed for now (they are not part of the EnrollMechanism allowlist, so the generic InvalidParameter error applies). A ListSlots method enumerates the currently enrolled keyslots. The dispatcher populates the same EnrollContext the command line uses and then runs the shared enroll_now()/prepare_luks()/wipe_slots() paths, so both front-ends behave identically. FIDO2 enrollment that requires user presence reports an imminent touch via a non-terminating "state":"touch" reply when the caller passes 'more'. Credential material (password, FIDO2 PIN, recovery key) is handled as sensitive, and key files may be passed either by path or as an fd index. The server is allocated root-only plus caller's-own-UID, with the listening socket created in 0644 mode. Replaces: systemd#31096
Conceptually a keyfile and a password are pretty much the same thing, hence put them in the same file.
THis simply tries TPM2 if available, and falls back to empty password.
Add a --firstboot mode that interactively walks the user through enrolling a passphrase, a recovery key, or a FIDO2 token, with one menu entry per suitable token currently plugged in (driven by a new fido2_enumerate_devices() helper). Pressing enter at the top-level menu leaves the volume unchanged; for each already-enrolled credential type the wizard offers to wipe it as part of the operation. It populates the same EnrollContext the command line and Varlink paths use, so the actual enrollment goes through the shared enroll_now() path. A companion --prompt-suppress= option takes a list of slot types: if a slot of any listed type already exists, the wizard does nothing and exits successfully. This lets it be hooked into the boot process while staying quiet once the system has been set up. The accompanying systemd-cryptenroll-firstboot.service runs this from the initrd, after systemd-repart has created the encrypted volume but before we transition to the host, suppressing itself once a password, recovery key or FIDO2 token is enrolled. To make that work, determine_default_node() now looks below /sysroot/ when running in the initrd, since the host file systems aren't at their final location yet. While the wizard is active it draws the same installer-style chrome (blue bars at the top and bottom of the terminal) as systemd-sysinstall, using the shared prompt_loop_yes_no() helper for its wipe confirmations. Honours the systemd.firstboot= kernel command line option. Fixes: systemd#36298
If we open this up to external processes let's tighten rules and refuse reading more than 4 MiB as key, after all this is locked memory.
Extend the existing systemd-cryptenroll test with varlinkctl invocations equivalent to the command line ones: enrolling a recovery key and passwords (unlocking via a key file by path and via a passed file descriptor), listing slots, combining enrollment with a type-based wipe, and the negative cases (ListSlots without 'more', and the pkcs11/tpm2 mechanisms that are not part of the EnrollMechanism allowlist).
I couldn't convince vmspawn to start a VM on a Fedora image I just downloaded, and it was pretty light on any useful details: $ build/systemd-vmspawn --image ~/Downloads/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x86_64.qcow2 --image-format=qcow2 --bind-ro=/tmp/bar; echo $? ░ Spawning VM Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x8664.qcow2 on /home/mrc0mmand/Downloads/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x86_64.qcow2. ░ Press Ctrl-] three times within 1s to kill VM. 1 Turns out that the unix socket path vmspawn generates for the virtiofsd socket is too long. Let's relay this information to the user as well to make debugging this a little less painful: $ build/systemd-vmspawn --image ~/Downloads/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x86_64.qcow2 --image-format=qcow2 --bind-ro=/tmp/bar ░ Spawning VM Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x8664.qcow2 on /home/mrc0mmand/Downloads/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x86_64.qcow2. ░ Press Ctrl-] three times within 1s to kill VM. Failed to prepare unix socket '/run/user/1000/systemd/vmspawn/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x8664.qcow2/sock-9594581dcf598992': File name too long
Amends 17260a9 (systemd#42524). Since there is no return path with an incomplete write, the effect of the memset block was unobservable, so drop it.
Add support for two newer NUMA memory policies: - MPOL_PREFERRED_MANY (Linux 5.15): like MPOL_PREFERRED but accepts a set of nodes instead of a single node, falling back to all nodes if preferred nodes cannot satisfy the allocation. - MPOL_WEIGHTED_INTERLEAVE (Linux 6.9): like MPOL_INTERLEAVE but distributes pages across nodes proportionally to per-node weights configured via /sys/kernel/mm/mempolicy/weighted_interleave/. On kernels that do not support the requested policy, set_mempolicy() returns EINVAL. We convert EINVAL to EOPNOTSUPP only for the two new policies (MPOL_PREFERRED_MANY, MPOL_WEIGHTED_INTERLEAVE), so that a bad NUMAMask= for already-supported policies still fails the service rather than being silently ignored. The NUMA subsystem being absent (ENOSYS) continues to be handled silently at debug level, as before. Varlink serialization uses json_underscorify() on an owned copy of the policy name string to convert hyphenated names to the underscore form declared in the IDL enum, avoiding mutation of the read-only static string table. Signed-off-by: dongshengyuan <dongshengyuan@uniontech.com>
--slice and --slice-inherit are intended to make the new service unit part of a specific slice. Logind is incompatible with that goal, as a session of any kind will prompt logind to immediately yoink the new command from the service unit into a new session scope, which does not inherit from run0's own slice. The use can still explicitly request a session with --setenv=XDG_SESSION_CLASS=<class>. Also make --slice and --slice-inherit conflict with --lightweight and --area, which depend on logind to be effective.
This reverts commit 7f33ee8. The file is located outside mkosi/ subdirectory, hence currently unused. If this is moved to mkosi/ subdirectory, the config conflicts with TEST-58-REPART. Let's remove it at least now, and reintroduce it later at correct place with test adjustment if this is really useful.
Adds dm-clone device setup at boot via a new /etc/clonetab config file, following the crypttab/veritytab pattern. - Add systemd-clonesetup-generator to parse /etc/clonetab and generate units. - Add systemd-clonesetup binary to create/remove dm-clone devices via ioctl. - Add clonesetup.target for ordering dm-clone activation at boot. - Add region_size= option in clonetab to configure dm-clone hydration granularity. - Add clonetab(5) and systemd-clonesetup-generator(8) man pages. Fixes: systemd#39500
src-up
pushed a commit
that referenced
this pull request
Jun 28, 2026
On i386 with musl and libucontext, many tests crash with SIGSEGV
when using fibers implemented on top of ucontext APIs.
For example:
```
929/1498 libsystemd - systemd:test-event-future FAIL 0.97s killed by signal 11 SIGSEGV
/* test_sd_event_run_timer */
run-suspend-timer: Scheduling fiber
/home/pmos/build/src/systemd-261-rc3/tools/test-crash-trace.sh: line 18: 19994 Segmentation fault (core dumped) "$@"
===== exit 139 — replaying under gdb =====
/* test_sd_event_run_timer */
run-suspend-timer: Scheduling fiber
Program received signal SIGSEGV, Segmentation fault.
0xf7d68be3 in sd_event_add_time_relative (e=0xf7ffd3f0, ret=0xf7b01fa0, clock=1, usec=10000, accuracy=0, callback=0x565564ad <inner_timer_handler>, userdata=0xf7b01fa4) at ../src/libsystemd/sd-event/sd-event.c:1455
1455 void *userdata) {
Thread 1 (process 20485 "test-event-futu"):
#0 0xf7d68be3 in sd_event_add_time_relative (e=0xf7ffd3f0, ret=0xf7b01fa0, clock=1, usec=10000, accuracy=0, callback=0x565564ad <inner_timer_handler>, userdata=0xf7b01fa4) at ../src/libsystemd/sd-event/sd-event.c:1455
t = 17868423377094431728
r = <optimized out>
#1 0x565574c7 in sd_event_run_timer_fiber (userdata=0x0) at ../src/libsystemd/sd-event/test-event-future.c:329
inner = 0xf7ffd3f0
source = 0x0
counter = 0
r = <optimized out>
systemd#2 0xf7dab308 in fiber_entry_point () at ../src/libsystemd/sd-future/fiber.c:208
_cleanup_log_unset_prefix_5 = 0x0
__unique_prefix_c6 = 0x5655bb30
f = 0xf7b06840
__func__ = "fiber_entry_point"
fake_stack_save = <optimized out>
systemd#3 0xf7b032ae in setcontext () from /lib/libucontext.so.1
No symbol table info available.
systemd#4 0x00000000 in ?? ()
No symbol table info available.
```
Building systemd with -mstackrealign makes all observed failures
disappear, suggesting a stack alignment issue in the interaction
between compiler-generated code and the ucontext implementation.
This resembles historical stack alignment issues in glibc's i386
makecontext() implementation, which required fixes to preserve the
expected stack alignment.
As a workaround, add -mstackrealign when building on i386 with musl
and libucontext.
Suggested-by: ChatGPT (OpenAI)
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
20 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.
No description provided.