On Tue, Aug 23, 2022 at 08:37:43AM -0700, Lalith Rajendran wrote: > Thank you for the comment. > Can you provide more details on how > https://lore.kernel.org/linux-fsdevel/20210417001026.23858-1-mcgrof@xxxxxxxxxx/ > is > related to your comment to freeze all filesystems in order? This all got started a long time ago[0] when I noticed that suspend often fails on my laptop because the kthread freezer will shut down some of XFS' low level background kernel threads before higher level background threads have been put to sleep. In this case, suspend kills the buffer IO completion thread before the XFS log worker, which means the log worker stalls trying to write the log contents back to disk: [0] https://lore.kernel.org/linux-xfs/20170203010401.GR9134@xxxxxxxxxxxxxxxx/ So I then proposed a patch[1] to mark the buffer completion workqueue as non-freezeable, which was rejected because while that will bandaid the suspend problem, it'll create bigger problems with hibernation because the log and buffer workers can keep running while hibernate tries to write the state of those threads out to disk: [1] https://lore.kernel.org/linux-xfs/20170327204611.GA4864@xxxxxxxxxxxxxxxx/ That came with a suggestion that the power management code should freeze the filesystems before trying to put kthreads to sleep. User programs will go to sleep trying to get write access, and all fs background threads will already be idle. Luis Chamberlain offered to pick up that work[2] back in 2017 to figure out how to freeze filesystems prior to suspend. His first attempt simply walked the supers list in reverse order, and drew quite a few comments. The second version[3] improved on that. [2] https://lore.kernel.org/all/20171003185313.1017-1-mcgrof@xxxxxxxxxx/T/#u [3] https://lore.kernel.org/all/20171129232356.28296-1-mcgrof@xxxxxxxxxx/T/#u Four years went by (I don't blame Luis; I've not had time to get back to this either) and his most recent posting[4] I think tried to restart the discussion. [4] https://lore.kernel.org/linux-fsdevel/20210417001026.23858-1-mcgrof@xxxxxxxxxx/ So that's where things stand now. I've idly wondered if a better approach would be to hook filesystems into the device model so that filesystems could watch for suspend notifications propagating down the device tree and turn that into a fsfreeze, but as I mentioned, I've had no time to figure out how that would really work since I'm not that familiar with how power management works in the kernel. I don't have a clue where you'd attach a network filesystem. --D > Thanks, > Lalith > > On Thu, Aug 18, 2022 at 5:08 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > On Thu, Aug 18, 2022 at 09:40:49PM +0000, Lalith Rajendran wrote: > > > ext4_lazyinit_thread is not set freezable. Hence when the thread calls > > > try_to_freeze it doesn't freeze during suspend and continues to send > > > requests to the storage during suspend, resulting in suspend failures. > > > > Maybe we should just make suspend freeze all the filesystems in order? > > > > > > https://lore.kernel.org/linux-fsdevel/20210417001026.23858-1-mcgrof@xxxxxxxxxx/ > > > > --D > > > > > Signed-off-by: Lalith Rajendran <lalithkraj@xxxxxxxxxx> > > > --- > > > fs/ext4/super.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c > > > index 9a66abcca1a85..d77e0904a1327 100644 > > > --- a/fs/ext4/super.c > > > +++ b/fs/ext4/super.c > > > @@ -3767,6 +3767,7 @@ static int ext4_lazyinit_thread(void *arg) > > > unsigned long next_wakeup, cur; > > > > > > BUG_ON(NULL == eli); > > > + set_freezable(); > > > > > > cont_thread: > > > while (true) { > > > -- > > > 2.31.0 > > > > >
