Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
Posted May 12, 2015 20:28 UTC (Tue) by pj (subscriber, #4506)Parent article: Trading off safety and performance in the kernel
Posted May 12, 2015 20:36 UTC (Tue)
by zuki (subscriber, #41808)
[Link] (9 responses)
Posted May 12, 2015 22:01 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (8 responses)
Racy in what sense?
Posted May 13, 2015 2:52 UTC (Wed)
by krakensden (subscriber, #72039)
[Link] (6 responses)
then there's a window between writing to disk and suspending the system where the in-memory filesystem cache can get dirtied.
Posted May 13, 2015 3:03 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (1 responses)
In the enter_state() function in kernel/power/suspend.c we have:
Posted May 13, 2015 3:41 UTC (Wed)
by chloe_zen (guest, #8258)
[Link]
Posted May 13, 2015 19:12 UTC (Wed)
by flussence (guest, #85566)
[Link] (3 responses)
Posted May 13, 2015 22:41 UTC (Wed)
by neilbrown (subscriber, #359)
[Link]
I wonder where this habit of using "-n" came from. Just
echo mem > /sys/power/state
If any file in /sys requires "echo -n" then that is kernel bug. Please report it.
Posted May 14, 2015 0:42 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted May 15, 2015 17:27 UTC (Fri)
by flussence (guest, #85566)
[Link]
Posted May 13, 2015 12:48 UTC (Wed)
by zuki (subscriber, #41808)
[Link]
I should have said "non-atomic". OP was wondering if a syscall option can be added to do configuration+execution in one step. I was just pointing out that the configuration step is already separate (e.g. for hibernation).
Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
#!/bin/sh
sync
echo -n mem > /sys/power/state
Thanks for being specific.
Trading off safety and performance in the kernel
trace_suspend_resume(TPS("sync_filesystems"), 0, true);
printk(KERN_INFO "PM: Syncing filesystems ... ");
sys_sync();
printk("done.\n");
trace_suspend_resume(TPS("sync_filesystems"), 0, false);
pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
error = suspend_prepare(state);
and in suspend_prepare():
pm_prepare_console();
error = pm_notifier_call_chain(PM_SUSPEND_PREPARE);
if (error)
goto Finish;
trace_suspend_resume(TPS("freeze_processes"), 0, true);
error = suspend_freeze_processes();
trace_suspend_resume(TPS("freeze_processes"), 0, false);
So the freezing of user-space processes happens *after* the sys_sync call. So that race is already present.
Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
> Racy in what sense?