From: Dave Chinner <david@fromorbit.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Jan Kara <jack@suse.cz>, "Rafael J. Wysocki" <rjw@sisk.pl>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fs / ext3: Always unlock updates in ext3_freeze()
Date: Tue, 23 Aug 2011 09:13:48 +1000 [thread overview]
Message-ID: <20110822231348.GS3162@dastard> (raw)
In-Reply-To: <20110822130045.GC11264@atrey.karlin.mff.cuni.cz>
On Mon, Aug 22, 2011 at 03:00:45PM +0200, Pavel Machek wrote:
> Hi!
>
> > > What's exactly the problem? Memory preallocation enters direct reclaim
> > > and that deadlocks in the filesystem?
> >
> > Well, that's one possible manifestation. The problem is that the
> > current hibernate code still assumes that sys_sync() results in an
> > idle filesystem that will not change after the call if nothing is
> > dirty.
> >
> > The result is that when the large memory allocation occurs for the
> > hibernate image (after the sys_sync() call) then the shrink_slab()
> > tends to be called. The XFS shrinkers are capable of dirtying inodes
> > and the backing buffers of inodes that are in the reclaimable state.
> > But those buffers cannot be flushed to disk because hibernate has
> > already frozen the xfsbufd threads, so the shrinker doing inode
> > reclaim hangs up on locks waiting for the buffers to be written.
> > This either leads to deadlock or hibernate image allocation failure.
> >
> > Far worse, IMO, is the case where is -doesn't- deadlock, because the
> > filesystem state can still changing after the allocation has
> > finished due to async metadata IO completions. That has the
> > potential to cause filesystem corruption as after resume the on-disk
> > state may not match what is written from memory to the hibernate
> > image.
> >
> > The problem really isn't XFS specific, nor is it new - the fact is
> > that any filesystem that has registered a shrinker or can do async
> > work in the background post-sync is vulnerable to this problem. It's
>
> Should we avoid calling shrinkers while hibernating?
If you like getting random OOM problems when hibernating, then go
for it. Besides, shrinkers are used for more than just filesystems,
so you might find you screw entire classes of users by doing this
(eg everyone using intel graphics and 3D).
> Or put BUG_ON()s into filesystem shrinkers so that this can not
> happen?
Definitely not. If your concern is filesystem shrinkers and you want
a large hammer to hit the problem with then do your hibernate
image allocation wih GFP_NOFS and the filesystem shrinkers will
abort without doing anything.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2011-08-22 23:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-11 21:29 [PATCH] Rafael J. Wysocki
2011-08-11 21:31 ` [PATCH] fs / ext3: Always unlock updates in ext3_freeze() Rafael J. Wysocki
2011-08-15 12:22 ` Jan Kara
2011-08-15 18:09 ` Rafael J. Wysocki
2011-08-15 20:58 ` Jan Kara
2011-08-15 22:07 ` Rafael J. Wysocki
2011-08-16 0:09 ` Dave Chinner
2011-08-16 18:20 ` Rafael J. Wysocki
[not found] ` <20110822130045.GC11264@atrey.karlin.mff.cuni.cz>
2011-08-22 23:13 ` Dave Chinner [this message]
2011-08-23 22:18 ` Rafael J. Wysocki
2011-08-25 13:49 ` Pavel Machek
2011-08-25 14:33 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110822231348.GS3162@dastard \
--to=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).