On Fri 21-03-25 13:00:24, James Bottomley via Lsf-pc wrote: > On Fri, 2025-03-21 at 08:34 -0400, James Bottomley wrote: > [...] > > Let me digest all that and see if we have more hope this time around. > > OK, I think I've gone over it all. The biggest problem with > resurrecting the patch was bugs in ext3, which isn't a problem now. > Most of the suspend system has been rearchitected to separate > suspending user space processes from kernel ones. The sync it > currently does occurs before even user processes are frozen. I think > (as most of the original proposals did) that we just do freeze all > supers (using the reverse list) after user processes are frozen but > just before kernel threads are (this shouldn't perturb the image > allocation in hibernate, which was another source of bugs in xfs). So as far as my memory serves the fundamental problem with this approach was FUSE - once userspace is frozen, you cannot write to FUSE filesystems so filesystem freezing of FUSE would block if userspace is already suspended. You may even have a setup like: bdev <- fs <- FUSE filesystem <- loopback file <- loop device <- another fs So you really have to be careful to freeze this stack without causing deadlocks. So you need to be freezing userspace after filesystems are frozen but then you have to deal with the fact that parts of your userspace will be blocked in the kernel (trying to do some write) waiting for the filesystem to thaw. But it might be tractable these days since I have a vague recollection that system suspend is now able to gracefully handle even tasks in uninterruptible sleep. > There's a final wrinkle in that if I plumb efivarfs into all this, it > needs to know whether it was a hibernate or suspend, but I can add that > as an extra freeze_holder flag. > > This looked like such a tiny can of worms when I opened it; now it > seems to be a lot bigger on the inside than it was on the outside, > sigh. Never underestimate the amount of worms in a can ;) Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
