Fix small typo in cr-restore.c #2780

tohanov · 2025-10-15T12:15:04Z

Super simple typo fix

Fixes: checkpoint-restore#2121 Signed-off-by: Pengda Yang <[email protected]>

This patch fixes the following warnings that appear when building an RPM package: + /usr/lib/rpm/redhat/brp-mangle-shebangs *** WARNING: ./usr/src/debug/criu-4.0-1.fc42.x86_64/plugins/amdgpu/amdgpu_plugin_util.c is executable but has no shebang, removing executable bit *** WARNING: ./usr/src/debug/criu-4.0-1.fc42.x86_64/plugins/amdgpu/amdgpu_plugin_util.h is executable but has no shebang, removing executable bit Signed-off-by: Radostin Stoyanov <[email protected]>

By default, CRIU uses the path "/usr/lib/criu" to install and load plugins at runtime. This path is defined by the `PLUGINDIR` variable in Makefile.install and `CR_PLUGIN_DEFAULT` in `criu/include/plugin.h`. However, some distribution packages might install the CRIU plugins at "/usr/lib64/criu" instead. This patch updates the makefile to align the path defined by `CR_PLUGIN_DEFAULT` with the value of `PLUGINDIR`. Signed-off-by: Radostin Stoyanov <[email protected]>

We only use the last pid from the list in NSpid entry (from /proc/<pid>/fdinfo/<pidfd>) while restoring pidfds. The last pid refers to the pid of the process in the most deeply nested pid namespace. Since CRIU does not currently support nested pid namespaces, this entry is the one we want. After Linux 6.9, inode numbers can be used to compare pidfds. pidfds referring to the same process will have the same inode numbers. We use inode numbers to restore pidfds that point to dead processes. Signed-off-by: Bhavik Sachdev <[email protected]>

Process file descriptors (pidfds) were introduced to provide a stable handle on a process. They solve the problem of pid recycling. For a detailed explanation, see https://lwn.net/Articles/801319/ and http://www.corsix.org/content/what-is-a-pidfd Before Linux 6.9, anonymous inodes were used for the implementation of pidfds. So, we detect them in a fashion similiar to other fd types that use anonymous inodes by calling `readlink()`. After 6.9, pidfs (a file system for pidfds) was introduced. In 6.9 `S_ISREG()` returned true for pidfds, but this again changed with 6.10. (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/pidfs.c?h=v6.11-rc2#n285) After this change, pidfs inodes have no file type in st_mode in userspace. We use `PID_FS_MAGIC` to detect pidfds for kernel >= 6.9 Hence, check for pidfds occurs before the check for regular files. For pidfds that refer to dead processes, we lose the pid of the process as the Pid and NSpid fields in /proc/<pid>/fdinfo/<pidfd> change to -1. So, we create a temporary process for each unique inode and open pidfds that refer to this process. After all pidfds have been opened we kill this temporary process. This commit does not include support for pidfds that point to a specific thread, i.e pidfds opened with `PIDFD_THREAD` flag. Fixes: checkpoint-restore#2258 Signed-off-by: Bhavik Sachdev <[email protected]>

Ensures that entries in /proc/<pid>/fdinfo/<pidfd> are same. Signed-off-by: Bhavik Sachdev <[email protected]>

Ensure `pidfd_send_signal()` syscall works as expected after C/R. Signed-off-by: Bhavik Sachdev <[email protected]>

Validate that pidfds can been used to send signals to different processes after C/R using the `pidfd_send_signal()` syscall. Signed-off-by: Bhavik Sachdev <[email protected]>

After, C/R of pidfds that point to dead processes their inodes might change. But if two pidfds point to same dead process they should continue to do so after C/R. This test ensures that this happens by calling `statx()` on pidfds after C/R and then comparing their inode numbers. Support for comparing pidfds by using `statx()` and inode numbers was introduced alongside pidfs. So if `f_type` of pidfd is not equal to `PID_FS_MAGIC` then we skip this test. signed-off-by: Bhavik Sachdev <[email protected]>

We get the read end of a pipe using `pidfd_getfd` and check if we can read from it after C/R. signed-off-by: Bhavik Sachdev <[email protected]>

We open a pidfd to a thread using `PIDFD_THREAD` flag and after C/R ensure that we can send signals using it with `PIDFD_SIGNAL_THREAD`. signed-off-by: Bhavik Sachdev <[email protected]>

The command `ruff <path>` has been deprecated and removed: https://astral.sh/blog/ruff-v0.5.0#removed-deprecated-features Signed-off-by: Radostin Stoyanov <[email protected]>

This patch fixes the following errors reported by ruff: lib/pycriu/images/pb2dict.py:307:24: E721 Use `is` and `is not` for type comparisons, or `isinstance()` for isinstance checks | 305 | elif field.type in _basic_cast: 306 | cast = _basic_cast[field.type] 307 | if pretty and (cast == int): | ^^^^^^^^^^^ E721 308 | if is_hex: 309 | # Fields that have (criu).hex = true option set | lib/pycriu/images/pb2dict.py:379:13: E721 Use `is` and `is not` for type comparisons, or `isinstance()` for isinstance checks | 377 | elif field.type in _basic_cast: 378 | cast = _basic_cast[field.type] 379 | if (cast == int) and is_string(value): | ^^^^^^^^^^^ E721 380 | if _marked_as_dev(field): 381 | return encode_dev(field, value) | Signed-off-by: Radostin Stoyanov <[email protected]>

This patch extends the inventory image with a `plugins` field that contains an array of plugins which were used during checkpoint, for example, to save GPU state. In particular, the CUDA and AMDGPU plugins are added to this field only when the checkpoint contains GPU state. This allows to disable unnecessary plugins during restore, show appropriate error messages if required CRIU plugin are missing, and migrate a process that does not use GPU from a GPU-enabled system to CPU-only environment. We use the `optional plugins_entry` for backwards compatibility. This entry allows us to distinguish between *unset* and *missing* field: - When the field is missing, it indicates that the checkpoint was created with a previous version of CRIU, and all plugins should be *enabled* during restore. - When the field is empty, it indicates that no plugins were used during checkpointing. Thus, all plugins can be *disabled* during restore. Signed-off-by: Radostin Stoyanov <[email protected]>

This patch adds two test plugins to verify that CRIU plugins listed in the inventory image are enabled, while those that are not listed can be disabled. Signed-off-by: Radostin Stoyanov <[email protected]>

This patch blocks SIGCHLD during temporary process creation to prevent a race condition between kill() and waitpid() where sigchld_handler() causes `criu restore` to fail with an error. Fixes: checkpoint-restore#2490 Signed-off-by: Bhavik Sachdev <[email protected]> Signed-off-by: Radostin Stoyanov <[email protected]>

Co-authored-by: Yixue Zhao <[email protected]> Co-authored-by: stove <[email protected]> Signed-off-by: Haorong Lu <[email protected]> --- - rebased - imported a page_size() type fix (authored by Cryolitia PukNgae) Signed-off-by: PukNgae Cryolitia <[email protected]> Signed-off-by: Alexander Mikhalitsyn <[email protected]>

Co-authored-by: Yixue Zhao <[email protected]> Co-authored-by: stove <[email protected]> Signed-off-by: Haorong Lu <[email protected]> --- - rebased - added a membarrier() to syscall table (fix authored by Cryolitia PukNgae) Signed-off-by: PukNgae Cryolitia <[email protected]> Signed-off-by: Alexander Mikhalitsyn <[email protected]>

Co-authored-by: Yixue Zhao <[email protected]> Co-authored-by: stove <[email protected]> Signed-off-by: Haorong Lu <[email protected]>

Signed-off-by: Haorong Lu <[email protected]>

Link: SerenityOS/serenity@e300da4 Signed-off-by: PukNgae Cryolitia <[email protected]> --- - cherry-picked Signed-off-by: Alexander Mikhalitsyn <[email protected]>

After a fork, both the child and parent processes may trigger a page fault (#PF) at the same virtual address, referencing the same position in the page image. If deduplication is enabled, the last process to trigger the page fault will fail. Therefore, deduplication should be disabled after a fork to prevent this issue. Signed-off-by: Liu Hua <[email protected]>

When restoring dumps in new mount + pid namespaces where multiple dumps share the same network namespace, CRIU may fail due to conflicting unix socket names. This happens because the service worker creates sockets using a pattern that includes criu_run_id, but util_init() is called after cr_service_work() starts. The socket naming pattern "crtools-fd-%d-%d" uses the restore PID and criu_run_id, however criu_run_id is always 0 when not initialized, leading to conflicts when multiple restores run simultaneously either in the same CRIU process or because of multiple CRIU processes doing the same operation in different PID namespaces. Fix this by: - Moving util_init() before cr_service_work() starts - Adding a second util_init() call in the service worker fork to ensure unique IDs across multiple worker runs - Making sure that dump and restore operations have util_init() called early to generate unique socket names With this fix, socket names always include the namespace ID, preventing conflicts when multiple processes with the same pid share a network namespace. Fixes checkpoint-restore#2499 [ avagin: minore code changes ] Signed-off-by: Lorenzo Fontana <[email protected]> Signed-off-by: Andrei Vagin <[email protected]>

When `check_freezer_cgroup()` has non-zero return value, `goto err` calls `return ret`. However, the value of `ret` has been set to `0` in the lines above and CRIU does not handle the error properly. This problem is related to checkpoint-restore#2508 Signed-off-by: Radostin Stoyanov <[email protected]>

Container runtimes like CRI-O and containerd utilize the freezer cgroup to create a consistent snapshot of container root filesystem (rootfs) changes. In this case, the container is frozen before invoking CRIU. After CRIU successfully completes, a copy of the container rootfs diff is saved, and the container is then unfrozen. However, the `cuda-checkpoint` tool is not able to perform a 'lock' action on frozen threads. To support GPU checkpointing with these container runtimes, we need to unfreeze the cgroup and return it to its original state once the checkpointing is complete. To reflect this new behavior, the following changes are applied: - `dont_use_freeze_cgroup(void)` -> `set_compel_interrupt_only_mode(void)` - `bool freeze_cgroup_disabled` -> `bool compel_interrupt_only_mode` - `check_freezer_cgroup(void)` -> `prepare_freezer_for_interrupt_only_mode(void)` Note that when `compel_interrupt_only_mode` is set to `true`, `compel_interrupt_task()` is used instead of `freeze_processes()` to prevent tasks from running during `criu dump`. Fixes: checkpoint-restore#2508 Signed-off-by: Radostin Stoyanov <[email protected]>

Signed-off-by: Radostin Stoyanov <[email protected]>

The check for `/dev/nvidiactl` to determine if the CUDA plugin can be used is unreliable because in some cases the default path for driver installation is different [1]. This patch changes the logic to check if a GPU device is available in `/proc/driver/nvidia/gpus/`. This approach is similar to `torch.cuda.is_available()` and it is a more accurate indicator. The subsequent check for support of the `cuda-checkpoint --action` option would confirm if the driver supports checkpoint/restore. [1] https://github.com/NVIDIA/gpu-operator Fixes: checkpoint-restore#2509 Signed-off-by: Radostin Stoyanov <[email protected]>

Currently, the `waitpid()` call on the tmp process can be made by a process which is not its parent. This causes restore to fail. This patch instead selects one process to create the tmp process and open all the fds that point to it. These fds are sent to the correct process(es). Fixes: checkpoint-restore#2496 Signed-off-by: Andrei Vagin <[email protected]> Signed-off-by: Bhavik Sachdev <[email protected]>

Currently we run aarch64 tests on both Cirrus CI and GitHub runners. However, Cirrus CI fails with "Monthly compute limit exceeded!". This change removes the redundant tests to streamline our CI process. Signed-off-by: Radostin Stoyanov <[email protected]>

Our previous mailing list had some technical issues and we created a new one that is hopefully more reliable. Signed-off-by: Radostin Stoyanov <[email protected]>

page_pipe_read() expects an 'unsigned long *', but pi->nr_pages is u64. On 32-bit platforms (e.g., armv7), passing &pi->nr_pages directly causes a compiler error. To fix this we introduce a temporary variable and copy the result back to pi->nr_pages. Fixes: checkpoint-restore#2756 Suggested-by: Andrei Vagin <[email protected]> Signed-off-by: Radostin Stoyanov <[email protected]>

Compilation on gentoo/arm64 (llvm+musl) fails with: In file included from compel/include/uapi/compel/asm/sigframe.h:4, from compel/plugins/std/infect.c:14: /usr/include/asm/sigcontext.h:28:8: error: redefinition of 'struct sigcontext' 28 | struct sigcontext { | ^~~~~~~~~~ In file included from criu/arch/aarch64/include/asm/restorer.h:4, from criu/arch/aarch64/crtools.c:11: /usr/include/asm/sigcontext.h:28:8: error: redefinition of 'struct sigcontext' 28 | struct sigcontext { | ^~~~~~~~~~ This is happening because <asm/sigcontext.h> and <signal.h> are mutually incompatible on Linux. To fix, use <signal.h> instead of <asm/sigcontext.h> for arm64 (like all others arches do). Fixes: checkpoint-restore#2766 Signed-off-by: Pepper Gray <[email protected]>

These tests reveal the following build error: In file included from compel/include/uapi/compel/asm/sigframe.h:4, from compel/plugins/std/infect.c:14: /usr/include/asm/sigcontext.h:28:8: error: redefinition of 'struct sigcontext' 28 | struct sigcontext { | ^~~~~~~~~~ In file included from criu/arch/aarch64/include/asm/restorer.h:4, from criu/arch/aarch64/crtools.c:11: /usr/include/asm/sigcontext.h:28:8: error: redefinition of 'struct sigcontext' 28 | struct sigcontext { | ^~~~~~~~~~ Inspired by checkpoint-restore#2766 / checkpoint-restore#2767. Signed-off-by: Kir Kolyshkin <[email protected]> Signed-off-by: Radostin Stoyanov <[email protected]>

Add a ZDTM test case where CRIU uses a helper process to restore a non-empty process group with a terminated leader and a Unix domain socket. This reproduces a corner case in which mount namespace switching can fail during restore: checkpoint-restore#2687 Signed-off-by: Qiao Ma <[email protected]> Signed-off-by: Radostin Stoyanov <[email protected]>

This flag will be used for a "[uprobes]" vma. Signed-off-by: Shashank Balaji <[email protected]>

Signed-off-by: Shashank Balaji <[email protected]>

This commit teaches criu to deal with processes which have a "[uprobes]" vma. This vma is mapped by the kernel when execution hits a uprobe location. This is done so as to execute the uprobe'd instruciton out-of-line in the special vma. The uprobe'd location is replaced by a software breakpoint instruction, which is int3 on x86. When execution reaches that location, control is transferred over to the kernel, which then executes whatever handler code it has to, for the uprobe, and then executed the replaced instruction out-of-line in the special vma. For more details, refer to this commit: torvalds/linux@d4b3b63 Reason for adding a new option ------------------------------ A new option is added instead of making the uprobes vma handling transparent to the user, so that when a dump is attempted on a process tree in which a process has the uprobes vma, criu will error, asking the user to use this option. This gives the user a chance to check what uprobes are attached to the processes being dumped, and try to ensure that those uprobes are active on restore as well. Again, the same reason for requiring this option on restore as well. Because if a process is dumped with an active uprobe, and on restore if the uprobe is not active, then if execution reaches the uprobe location, then the process will be sent a SIGTRAP, whose default behaviour will terminate and core dump the process. This is because the code pages are dumped with the software breakpoint instruction replacement at the uprobe'd locations. On restore, if execution reaches these locations and the kernel sees no associated active uprobes, then it'll send a SIGTRAP. So, using this option is on dump and restore is an implicit guarantee on the user's behalf that they'll take care of the active uprobes and that any future SIGTRAPs because of this are not on us! :) Handling uprobes vma on dump ---------------------------- We don't need to store any information about the uprobes vma because it's completely handled by the kernel, transparent to userspace. So, when a uprobes vma is detected, we check if the --allow-uprobes option was specified or not. If so, then the allow_uprobes boolean in the inventory image is set (this is used on restore). The uprobes vma is skipped from being added to the vma list. Handling uprobes vma on restore ------------------------------- If allow_uprobes is set in the inventory image, then check if --allow-uprobes is specified or not. Restoring the vma is not required. Fixes: checkpoint-restore#1961 Signed-off-by: Shashank Balaji <[email protected]>

Signed-off-by: Shashank Balaji <[email protected]>

Most people know this, don't they? :) Suggested-by: Radostin Stoyanov <[email protected]> Signed-off-by: Shashank Balaji <[email protected]>

Program flow: - Parse the test's own executable to calculate the file offset of the uprobe target function symbol - Enable the uprobe at the target function - Call the target function to trigger the uprobe, and hence the uprobes vma creation - C/R - Call the target function again to check that no SIGTRAP is sent, since the uprobe is still active At least v1.7 of libtracefs is required because that's when tracefs_instance_reset was introduced. The uprobes API was introduced in v1.4, and the dynamic events API was introduced in v1.3. Ubuntu Focal doesn't have libtracefs. Jammy has v1.2.5, and Noble has v1.7. Signed-off-by: Shashank Balaji <[email protected]>

When an additional configuration file is specified via RPC, this file is parsed twice: first at an early stage to load options such as --log-file, --work-dir, and --images-dir; and again after all RPC options and configuration files have been evaluated. This allows users to overwrite options specified via RPC by the container runtime (e.g., --tcp-established). However, processing the RPC config file twice leads to silently duplicating the values of repeatable options such as `--action-script`. To address this problem, we adjust the order of options parsing so that the RPC config file is evaluated only once. This change should not introduce any functional changes. Note that this change does not affect the logging functionality, as early log messages are temporarily buffered and only written to the log file once it has been initialized (see commit 1ff2333 "Printout early log messages"). Fixes checkpoint-restore#2727 Suggested-by: Andrei Vagin <[email protected]> Signed-off-by: Radostin Stoyanov <[email protected]>

Extend the test for overwriting config options via RPC with repeatable option (--action-script) and verify that the value will not be silently duplicated. Signed-off-by: Radostin Stoyanov <[email protected]>

Signed-off-by: Radostin Stoyanov <[email protected]>

avagin · 2025-10-15T18:38:29Z

Please format the commit message properly. A sign-off email should be a valid email address that can be used to communicate with the author.

tohanov · 2025-10-16T22:29:21Z

Please format the commit message properly. A sign-off email should be a valid email address that can be used to communicate with the author.

I've fixed the email address.
Not sure what you mean by formatting the commit message properly.

rst0git · 2025-10-18T08:24:27Z

@tohanov The following contributor guidelines provide more information on how to format commit messages:

https://github.com/checkpoint-restore/criu/blob/criu-dev/CONTRIBUTING.md

herheliuk · 2025-10-20T04:21:56Z

@tohanov

Basically you can't do it here on GitHub. (as far as I know)

copy your forked repo to your machine with the following command:

git clone https://github.com/tohanov/criu --branch patch-1

open the folder and run these two commands:

git branch -m patch-1
git remote add origin https://github.com/tohanov/criu

edit last commit:

git commit --amend

e.g. using following format:

[component]: [commit message]

[description]

Signed-off-by: Your Name <[email protected]>

save & exit with: Ctrl + X, Shift + Y, Enter. I'd do:

cr-restore: typo fix

Changed 'do' to 'does'

Signed-off-by: :| <[email protected]>

force push, this should update this PR automatically.

git push origin patch-1 --force

Any questions or issues during the process, you may ask ChatGPT (no login required).

You are very welcome.

tohanov · 2025-10-25T22:39:18Z

I fixed the commit message

herheliuk · 2025-10-27T22:47:55Z

@tohanov, you forgot < and > by your email.

Changed 'do' to 'does' in a log message. Signed-off-by: :| <[email protected]>

tohanov · 2025-10-29T22:01:15Z

😅 whoops
Now it's ok hopefully

avagin · 2025-10-30T16:20:27Z

Just a reminder: CRIU does not accept contributions from anonymous or pseudonymous individuals. This policy is primarily driven by legal and licensing requirements.

I would prefer to see a verifiable name instead of :|. Currently, this sign-off tag looks suspicious to me, and I would recommend we ignore this minor change.

Daz-3ux and others added 30 commits October 26, 2024 22:17

limit the field width of 'scanf'

810f52e

Fixes: checkpoint-restore#2121 Signed-off-by: Pengda Yang <[email protected]>

zdtm: Check pidfd fdinfo entry is consistent

f9fdfca

Ensures that entries in /proc/<pid>/fdinfo/<pidfd> are same. Signed-off-by: Bhavik Sachdev <[email protected]>

zdtm: Check pidfd can send signal after C/R

487853f

Ensure `pidfd_send_signal()` syscall works as expected after C/R. Signed-off-by: Bhavik Sachdev <[email protected]>

zdtm: Check pidfd can kill descendant processes

032a822

Validate that pidfds can been used to send signals to different processes after C/R using the `pidfd_send_signal()` syscall. Signed-off-by: Bhavik Sachdev <[email protected]>

zdtm: Check fd from pidfd_getfd is C/Red correctly

98c49d0

We get the read end of a pipe using `pidfd_getfd` and check if we can read from it after C/R. signed-off-by: Bhavik Sachdev <[email protected]>

zdtm: Check pidfd for thread is valid after C/R

b88d40e

We open a pidfd to a thread using `PIDFD_THREAD` flag and after C/R ensure that we can send signals using it with `PIDFD_SIGNAL_THREAD`. signed-off-by: Bhavik Sachdev <[email protected]>

make/lint: use 'ruff check <path>'

0e78014

The command `ruff <path>` has been deprecated and removed: https://astral.sh/blog/ruff-v0.5.0#removed-deprecated-features Signed-off-by: Radostin Stoyanov <[email protected]>

zdtm: add inventory test plugins

e6ce8f4

This patch adds two test plugins to verify that CRIU plugins listed in the inventory image are enabled, while those that are not listed can be disabled. Signed-off-by: Radostin Stoyanov <[email protected]>

images: add riscv64 core image

1a42f63

Co-authored-by: Yixue Zhao <[email protected]> Co-authored-by: stove <[email protected]> Signed-off-by: Haorong Lu <[email protected]>

criu: add riscv64 support to parasite and restorer

35b3077

Co-authored-by: Yixue Zhao <[email protected]> Co-authored-by: stove <[email protected]> Signed-off-by: Haorong Lu <[email protected]>

zdtm: add riscv64 support

6636782

Signed-off-by: Haorong Lu <[email protected]>

ci: add workflow for riscv64

9863769

Signed-off-by: Haorong Lu <[email protected]>

include: don't use GCC's __builtin_ffs on riscv64

f6baf81

Link: SerenityOS/serenity@e300da4 Signed-off-by: PukNgae Cryolitia <[email protected]> --- - cherry-picked Signed-off-by: Alexander Mikhalitsyn <[email protected]>

ci: test interrupt-only mode with frozen cgroup

31b38d6

Signed-off-by: Radostin Stoyanov <[email protected]>

rst0git and others added 16 commits September 30, 2025 07:38

contributing: update links to mailing list

6549697

Our previous mailing list had some technical issues and we created a new one that is hopefully more reliable. Signed-off-by: Radostin Stoyanov <[email protected]>

vma: introduce VMA_AREA_UPROBES flag

b2bed94

This flag will be used for a "[uprobes]" vma. Signed-off-by: Shashank Balaji <[email protected]>

criu-coredump: add VMA_AREA_UPROBES flag

fc8ed5b

Signed-off-by: Shashank Balaji <[email protected]>

crit: add VMA_AREA_UPROBES flag

beba269

Signed-off-by: Shashank Balaji <[email protected]>

docs: add documentation for --allow-uprobes

61dddfe

Signed-off-by: Shashank Balaji <[email protected]>

crtools: remove "consult documentation"

f0e6b6d

Most people know this, don't they? :) Suggested-by: Radostin Stoyanov <[email protected]> Signed-off-by: Shashank Balaji <[email protected]>

test/others/rpc: parse action-script via config

3dde833

Extend the test for overwriting config options via RPC with repeatable option (--action-script) and verify that the value will not be silently duplicated. Signed-off-by: Radostin Stoyanov <[email protected]>

test/others/rpc: show logs on error

c14c2ae

Signed-off-by: Radostin Stoyanov <[email protected]>

tohanov force-pushed the patch-1 branch from eccba9b to 66dc8b2 Compare October 22, 2025 22:40

cr-restore: Fix log message typo

4faffd1

Changed 'do' to 'does' in a log message. Signed-off-by: :| <[email protected]>

tohanov force-pushed the patch-1 branch from 66dc8b2 to 4faffd1 Compare October 29, 2025 21:55

avagin marked this pull request as draft October 30, 2025 16:20

avagin force-pushed the criu-dev branch from a1fd7e6 to 9204372 Compare November 14, 2025 18:30

tohanov closed this Nov 16, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix small typo in cr-restore.c #2780

Fix small typo in cr-restore.c #2780

Uh oh!

tohanov commented Oct 15, 2025 •

edited

Loading

Uh oh!

avagin commented Oct 15, 2025

Uh oh!

tohanov commented Oct 16, 2025 •

edited

Loading

Uh oh!

rst0git commented Oct 18, 2025

Uh oh!

herheliuk commented Oct 20, 2025 •

edited

Loading

Uh oh!

tohanov commented Oct 25, 2025

Uh oh!

herheliuk commented Oct 27, 2025

Uh oh!

tohanov commented Oct 29, 2025

Uh oh!

avagin commented Oct 30, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

31 participants

Fix small typo in cr-restore.c #2780

Fix small typo in cr-restore.c #2780

Uh oh!

Conversation

tohanov commented Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

avagin commented Oct 15, 2025

Uh oh!

tohanov commented Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rst0git commented Oct 18, 2025

Uh oh!

herheliuk commented Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tohanov commented Oct 25, 2025

Uh oh!

herheliuk commented Oct 27, 2025

Uh oh!

tohanov commented Oct 29, 2025

Uh oh!

avagin commented Oct 30, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

31 participants

tohanov commented Oct 15, 2025 •

edited

Loading

tohanov commented Oct 16, 2025 •

edited

Loading

herheliuk commented Oct 20, 2025 •

edited

Loading