Open stapelberg opened 5 years ago
Miklos let me know that there has been no change on that issue. We should look into patching the freezing code to always order the distri fuse process last. It might be easy enough to special case.
With this patch, I’m still encountering the same symptom:
--- linux-5.1.9/kernel/power/process.c 2019-06-11 12:19:23.000000000 +0200
+++ /home/michael/distri/linux-5.1.9/kernel/power/process.c 2019-07-18 08:26:03.567185226 +0200
@@ -38,6 +38,7 @@
unsigned int elapsed_msecs;
bool wakeup = false;
int sleep_usecs = USEC_PER_MSEC;
+ char comm[TASK_COMM_LEN];
start = ktime_get_boottime();
@@ -45,16 +46,23 @@
if (!user_only)
freeze_workqueues_begin();
-
+
while (true) {
todo = 0;
read_lock(&tasklist_lock);
- for_each_process_thread(g, p) {
+ for_each_process_thread(g /* process */, p /* thread */) {
+ if (strcmp(get_task_comm(comm, g), "init") == 0) {
+ pr_info("skipping FUSE pid %d\n", g->pid);
+ continue;
+ }
+
if (p == current || !freeze_task(p))
continue;
- if (!freezer_should_skip(p))
+ if (!freezer_should_skip(p)) {
+ pr_info("todo: pid %d (comm=%s)\n", g->pid, get_task_comm(comm, g));
todo++;
+ }
}
read_unlock(&tasklist_lock);
@@ -81,6 +89,17 @@
sleep_usecs *= 2;
}
+ // Acquire the locks just in case they influence freeze_task().
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g /* process */, p /* thread */) {
+ if (strcmp(get_task_comm(comm, g), "init") != 0) {
+ continue;
+ }
+ pr_info("freezing init pid %d (comm=%s)\n", g->pid, get_task_comm(comm, g));
+ freeze_task(p);
+ }
+ read_unlock(&tasklist_lock);
+
end = ktime_get_boottime();
elapsed = ktime_sub(end, start);
elapsed_msecs = ktime_to_ms(elapsed);
Applying https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1696923 in addition fixes (works around?) the issue.
With the patch applied, this is no longer a release blocker :)
Most likely, we are running into https://lists.debian.org/debian-kernel/2011/10/msg00412.html.
I’ve reached out to Miklos to see what the latest status on that issue is.