linux-kernel - Re: [xfs-masters] Re: freeze vs freezer

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: <200806302300.45018.rjw@sisk.pl>
Date:	Mon, 30 Jun 2008 23:00:43 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Dave Chinner <david@...morbit.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>, xfs-masters@....sgi.com,
	Elias Oltmanns <eo@...ensachen.de>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Kyle Moffett <mrmacman_g4@....com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	David Chinner <dgc@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [xfs-masters] Re: freeze vs freezer

On Monday, 30 of June 2008, Dave Chinner wrote:
> On Sun, Jun 29, 2008 at 11:37:31PM -0700, Jeremy Fitzhardinge wrote:
> > Dave Chinner wrote:
> >> On Mon, Jun 30, 2008 at 01:22:47AM +0200, Rafael J. Wysocki wrote:
> >>> On Monday, 30 of June 2008, Dave Chinner wrote:
> >>>> On Thu, Jun 26, 2008 at 05:09:10PM +0200, Pavel Machek wrote:
> >>>>>>> Is this the same thing the per-device IO-queue-freeze patches for
> >>>>>>> HDAPS also
> >>>>>>> need to do?  If so, you may want to talk to Elias Oltmanns
> >>>>>>> <eo@...ensachen.de> about it.  Added to CC.
> >>>>>>>             
> >>>>>> Thanks for the heads up Henrique. Even though these issues seem to be
> >>>>>> related up to a certain degree, there probably are some important
> >>>>>> differences. When suspending a system, the emphasis is on leaving the
> >>>>>> system in a consistent state (think of journalled file systems), whereas
> >>>>>> disk shock protection is mainly concerned with stopping I/O as soon as
> >>>>>> possible. As yet, I cannot possibly say to what extend these two
> >>>>>> concepts can be reconciled in the sense of sharing some common code.
> >>>>>>           
> >>>>> Actually, I believe requirements are same.
> >>>>>
> >>>>> 'don't do i/o in dangerous period'.
> >>>>>
> >>>>> swsusp will just do sync() before entering dangerous period. That
> >>>>> provides consistent-enough state...
> >>>>>         
> >>>> As I've said many times before - if the requirement is "don't do
> >>>> I/O" then you have to freeze the filesystem. In no way does 'sync'
> >>>> prevent filesystems from doing I/O.....
> >>>>       
> >>> Well, it seems we can handle this on the block layer level, by temporarily
> >>> replacing the elevator with something that will selectively prevent fs I/O
> >>> from reaching the layers below it.
> >>
> >> Why? What part of freeze_bdev() doesn't work for you?
> >
> > Well, my original problem - which is still an issue - is that a process  
> > writing to a frozen XFS filesystem is stuck in D state, and therefore  
> > cannot be frozen as part of suspend.

I thought we were talking about the post-freezer situation.

> Silly me - how could I forget the three headed monkey getting in
> the way of our happy trip to beer island?
> 
> Seriously, though, how is stopping I/O in the elevator is going to
> change that?

We can do that after creating the image and before we let devices run again.
This way we won't need to worry about the freezer.

> What do you do with a sync I/O (read or write)? The 
> process is going to have to go to sleep somewhere in D state waiting
> for that I/O to complete.  If you're going to intercept such
> processes somewhere else to do something magic, then why not put
> that magic in vfs_check_frozen()?

This might work too, but it would be nice to do something independent of the
freezer, so that we can drop the freezer when we want and not when we are
forced to.

Thanks,
Rafael
--
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/