On Thu, 2025-03-20 at 09:48 -0700, Christoph Hellwig wrote: > On Thu, Mar 20, 2025 at 11:36:17AM -0400, James Bottomley wrote: > > Part of the thought here is that other filesystems might possibly > > want suspend resume hooks as well, although not for the reasons > > efivarfs does: Hibernate is a particularly risky operation and > > resume may not work leading to a full reboot and filesystem > > inconsistencies. In many ways, a failed resume is exactly like a > > system crash, for which filesystems already make specific > > guarantees. However, it is a crash for which they could, if they > > had power management hooks, be forewarned and possibly make the > > filesystem cleaner for eventual full restore. Things like > > guaranteeing that uncommitted data would be preserved even > > if a resume failed, which isn't something we guarantee across a > > crash today. > > We finally got hibernate to freeze file system on suspend, which is > the right thing for the above reasons. Agreed, so perhaps there are no other reasons a real filesystem would like to know. > This might not work quite as well for virtual file systems tied to an > actualy resource like efivarsfs, so you might just register a fake > device to get the system suspend/resume notifications for it. Or > whatever better way the PM and device model maintainers things that > suites, but definitively something that isn't a file system > interface. Yes, we register a blocking notifier for power management via register_pm_notifier() so no device is involved (useful because we don't have one). The notifier is unregistered in ->kill_sb() which is why we get "interesting" deadlock possibilities. Regards, James
