Suspend to RAM does not works while `rr replay` processes are running.

I have no idea if this is a Linux kernel issue or a rr issue. I do not even know if there is any notifications send to the process which can make this bug actionable within rr. In the mean time, I noticed that I am unable to suspend rr exec_stub processes to ram while I have debugging sessions running.

When triggering a suspend to RAM, I got reports with the following lines in dmesg.

[283009.174166] Freezing of tasks failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0):
[283009.174218] mmap_1_hardlink D ffff88047e212c80     0  2896   2882 0x00010046
[283009.174220]  ffff8803b510fb28 0000000000000086 ffff88046731c400 0000000000012c80
[283009.174222]  ffff8803b510ffd8 0000000000012c80 ffff88046731b300 ffff88046731c400
[283009.174224]  ffff880466590880 ffff8803b510fd50 7fffffffffffffff ffff8803b510fd48
[283009.174226] Call Trace:
[283009.174233]  [<ffffffff814b17b9>] schedule+0x29/0x70
[283009.174235]  [<ffffffff814b472c>] schedule_timeout+0x1ac/0x290
[283009.174238]  [<ffffffff8108badd>] ? ttwu_do_activate.constprop.105+0x5d/0x70
[283009.174241]  [<ffffffff8108e588>] ? try_to_wake_up+0x1d8/0x300
[283009.174243]  [<ffffffff814b23de>] wait_for_completion+0x9e/0x110
[283009.174245]  [<ffffffff8108e720>] ? wake_up_state+0x20/0x20
[283009.174248]  [<ffffffff81207c4d>] do_coredump+0x33d/0xea0
[283009.174250]  [<ffffffff814b121a>] ? __schedule+0x2ea/0x860
[283009.174254]  [<ffffffff81070101>] ? compat_ptrace_request+0x91/0x220
[283009.174256]  [<ffffffff8107428f>] get_signal+0x21f/0x610
[283009.174259]  [<ffffffff81057677>] ? bad_area+0x47/0x60
[283009.174264]  [<ffffffff810124e8>] do_signal+0x28/0x720
[283009.174266]  [<ffffffff8107403b>] ? ptrace_notify+0x5b/0x90
[283009.174268]  [<ffffffff81070000>] ? ptrace_request+0x580/0x5b0
[283009.174272]  [<ffffffff811adbfc>] ? vfs_write+0x15c/0x1f0
[283009.174275]  [<ffffffff81012c50>] do_notify_resume+0x70/0x90
[283009.174277]  [<ffffffff814b67a2>] retint_signal+0x48/0x86

Looking up the pid, highlights that these are only rr processes.

$ ls -l /proc/2882/exe /proc/2896/exe
lrwxrwxrwx 1 nicolas nicolas 0 Feb 17 10:35 /proc/2882/exe -> /nix/store/niwpml90jdzkm83a4d1va5zhkwb73zmr-rr-4.1.0-35-g93b3630/bin/exec_stub*
lrwxrwxrwx 1 nicolas nicolas 0 Feb 17 10:35 /proc/2896/exe -> /nix/store/niwpml90jdzkm83a4d1va5zhkwb73zmr-rr-4.1.0-35-g93b3630/bin/exec_stub*

Looking for the status (/proc/$pid/status) of the processes, I got the following information:

$ head -n 7 /proc/2882/status                          
Name:   JS Helper
State:  t (tracing stop)
Tgid:   2882
Ngid:   0
Pid:    2882
PPid:   1
TracerPid:      31896

$ head -n 7 /proc/2896/status                          
Name:   mmap_1_hardlink
State:  D (disk sleep)
Tgid:   2895
Ngid:   0
Pid:    2896
PPid:   2882
TracerPid:      31896

Start by reproducing suspend to RAM while an rr replay debugging session is running, then compare dmesg with /proc/$pid/exe and /proc/$pid/status for the affected exec_stub processes. Determine whether the blocking behavior is actionable in rr or belongs to the Linux kernel; done means identifying the responsible component and a clear path to resolving or reporting it.