The problematic kthread freezer

Posted Nov 3, 2016 2:03 UTC (Thu) by trondmy (subscriber, #28934)
Parent article: The problematic kthread freezer

> It might be necessary to keep it around for NFS, he said, but there's not much else that should need it.

Thanks for the offer, but no thanks. The kthread freezer is borked for NFS as well, and we'd rather get rid of it.

The problematic kthread freezer

Posted Nov 3, 2016 11:26 UTC (Thu) by jlayton (subscriber, #31672) [Link] (2 responses)

Agreed. As we discussed recently, I think the right solution is to wire up the fs_freeze mechanism for NFS to quiesce it like we would any other filesystem. The machine suspending would fs_freeze all of its filesystems and then go to sleep.

The problematic kthread freezer

Posted Nov 5, 2016 14:53 UTC (Sat) by jikos (subscriber, #43140) [Link] (1 responses)

That'd be awesome; if you could then CC me once the ->freeze_fs() callback implementation is going in, I'd immediately proceed, as that'd remove the one of the biggest current roadblocks blocking my "move hibernation towards fs freezing and kill kthread freezer" patchset. Thanks.

The problematic kthread freezer

Posted Nov 9, 2016 15:29 UTC (Wed) by jlayton (subscriber, #31672) [Link]

Well, I handwaved that a bit. It _is_ rather tricky to wire up for NFS.

Basically what I think we'd want to do is to have fsfreeze tell the RPC transport layer that it should stop sending RPCs to the server(s) and drain the queue by waiting on replies to come in.

The question though is what to do with threads sitting in syscalls that need to issue an RPC. "Parking" them down at the layer where we're synchronously waiting for an RPC reply would be bad, as it would mean that we could easily be holding vfs-layer locks at that point (inode->i_rwsem for instance).

How should that work?