linux-kernel - Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system suspend/hibernation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Feb 2012 10:03:28 +0100
From:	Jan Kara <jack@...e.cz>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Pavel Machek <pavel@....cz>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM list <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, Jan Kara <jack@...e.cz>,
	linux-fsdevel@...r.kernel.org, Dave Chinner <david@...morbit.com>,
	Nigel Cunningham <nigel@...onice.net>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH] PM / Sleep: Freeze filesystems during system
 suspend/hibernation

On Fri 10-02-12 02:52:17, Jamie Lokier wrote:
> Alan Stern wrote:
> > On Wed, 1 Feb 2012, Pavel Machek wrote:
> > 
> > > > particular, this should help to solve a long-standing issue that, in
> > > > some cases, during resume from hibernation the boot loader causes the
> > > > journal to be replied for the filesystem containing the kernel image
> > > > and/or initrd causing it to become inconsistent with the information
> > > > stored in the hibernation image.
> > > 
> > > Ungood. Why is bootloader/initrd doing that? If it mounts filesystem
> > > read/write, what is the guarantee that it will not change data on the
> > > filesystem, breaking stuff?
> > > 
> > > Bootloaders should just not replay journals.
> > > 
> > > > The user-space-driven hibernation (s2disk) is not covered by this
> > > > change, because the freezing of filesystems prevents s2disk from
> > > > accessing device special files it needs to do its job.
> > > 
> > > ...so bootloaders need to be fixed, anyway.
> > 
> > I don't know about bootloaders, but from what I've heard, Linux fs
> > drivers (including those inside initrds) always replay the journal,
> > even if the filesystem is mounted read-only.  This could be considered
> > a bug in the filesystem code.
> 
> Theoretically a filesystem might need replay for the bootloader to see
> a non-corrupt image, even for just the files it uses.
> 
> For example if the last state was in the middle of updating the root
> directory, the /boot entry in the root directory might not be reliably
> found without replaying the journal.
> 
> However replaying a journal when mounted read-only should probably
> track journalled blocks in memory only, not commit back to the storage.
  Yes, that would be nice. Although memory constraints of the bootloader
might make it tricky.

  The reason why we don't have the functionality in kernel is not so much
about memory demands but more about the complexities of implementing the
caching - we'd have to create an equivalent of dm-snapshot of the device
from the mount code to trick generic code in pagecache to loading proper
replayed data).

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/