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
| ||
|
Date: Tue, 14 Nov 2006 11:10:07 +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 Mon, Nov 13, 2006 at 05:22:54PM +0100, Rafael J. Wysocki wrote: > On Monday, 13 November 2006 06:43, David Chinner wrote: > > On Sun, Nov 12, 2006 at 11:43:05PM +0100, Rafael J. Wysocki wrote: > > Before or after freezing of the kthreads? Order _could_ be > > important, and different filesystems might require different > > orders. What then? > > Well, I don't really think the order is important. If the freezing of work > queues is done by the freezing of their respective worker threads, the > other threads won't even know they have been frozen. True - I just think that some defined ordering semantics might be helpful for people trying to use workqueues and kthreads in the future. It would also help us determine if the current usage is safe as well... > > > 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. > > Even if it's not idle, we are safe as long as the I/O activity doesn't > continue after the suspend image has been created. And that is my great concern - there really is nothing to prevent a fs from having I/O outstanding while the suspend image is being created. > > Rather than assuming the filesystem is idle, why not guarantee > > that it is idle by freezing it? > > Well, _I_ personally think that the freezing of filesystems is the right thing > to do, although it may lead to some complications down the road. *nod* I would also prefer to start with something we know is safe and work from there. 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/
Powered by blists - more mailing lists