linux-kernel - Re: [PATCH 2.6.19 5/5] fs: freeze

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]

Message-ID: <20061113054340.GP11034@melbourne.sgi.com>
Date:	Mon, 13 Nov 2006 16:43:40 +1100
From:	David Chinner <dgc@....com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	David Chinner <dgc@....com>, Pavel Machek <pavel@....cz>,
	Alasdair G Kergon <agk@...hat.com>,
	Eric Sandeen <sandeen@...hat.com>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	dm-devel@...hat.com, Srinivasa DS <srinivasa@...ibm.com>,
	Nigel Cunningham <nigel@...pend2.net>
Subject: Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex

On Sun, Nov 12, 2006 at 11:43:05PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 12 November 2006 23:30, David Chinner wrote:
> > On Fri, Nov 10, 2006 at 11:39:42AM +0100, Pavel Machek wrote:
> > > On Fri 2006-11-10 11:57:49, David Chinner wrote:
> > > > On Thu, Nov 09, 2006 at 11:21:46PM +0100, Rafael J. Wysocki wrote:
> > > > > I think we can add a flag to __create_workqueue() that will indicate if
> > > > > this one is to be running with PF_NOFREEZE and a corresponding macro like
> > > > > create_freezable_workqueue() to be used wherever we want the worker thread
> > > > > to freeze (in which case it should be calling try_to_freeze() somewhere).
> > > > > Then, we can teach filesystems to use this macro instead of
> > > > > create_workqueue().
> > > > 
> > > > At what point does the workqueue get frozen? i.e. how does this
> > > > guarantee an unfrozen filesystem will end up in a consistent
> > > > state?
> > > 
> > > Snapshot is atomic; workqueue will be unfrozen with everyone else, but
> > > as there were no writes in the meantime, there should be no problems.
> > 
> > That doesn't answer my question - when in the sequence of freezing
> > do you propose diasbling the workqueues? before the kernel threads,
> > after the kernel threads, before you sync the filesystem?
> 
> After the sync, along with the freezing of kernel threads.

Before or after freezing of the kthreads? Order _could_ be
important, and different filesystems might require different
orders. What then?

> > And how does freezing them at that point in time guarantee consistent
> > filesystem state?
> 
> If the work queues are frozen, there won't be any fs-related activity _after_
> we create the suspend image.

What about if there is still I/O in progress (i.e. kthread wins race and
issues async I/O after the sync but before it's frozen) - freezing the
workqueues does not prevent this activity and memory state will continue to
change as long as there is I/O completing...

> The sync is done after the userland has been
> frozen, so if the resume is unsuccessful, we'll be able to recover the state
> of the fs right before the sync,

Yes, in most cases.

> and if the resume is successful, we'll be
> able to continue (the state of memory will be the same as before the creation
> of the suspend image and the state of the disk will be the same as before the
> creation of the suspend image).

Assuming that you actually suspended an idle filesystem, which sync does not
guarantee you.  Rather than assuming the filesystem is idle, why not guarantee
that it is idle by freezing it?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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/