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]

Date:	Thu, 09 Nov 2006 07:48:20 +1100
From:	Nigel Cunningham <nigel@...pend2.net>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	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>
Subject: Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex

Hi.

On Wed, 2006-11-08 at 13:10 +0100, Rafael J. Wysocki wrote:
> On Wednesday, 8 November 2006 03:30, Alasdair G Kergon wrote:
> > On Tue, Nov 07, 2006 at 11:49:51PM +0000, Alasdair G Kergon wrote:
> > > I hadn't noticed that -mm patch.  I'll take a look.  
> > 
> > swsusp-freeze-filesystems-during-suspend-rev-2.patch
> > 
> > I think you need to give more thought to device-mapper
> > interactions here.  If an underlying device is suspended
> > by device-mapper without freezing the filesystem (the
> > normal state) and you issue a freeze_bdev on a device
> > above it, the freeze_bdev may never return if it attempts
> > any synchronous I/O (as it should).
> 
> Well, it looks like the interactions with dm add quite a bit of
> complexity here.
> 
> > Try:
> >   while process generating I/O to filesystem on LVM
> >   issue dmsetup suspend --nolockfs (which the lvm2 tools often do)
> >   try your freeze_filesystems()
> 
> Okay, I will.
> 
> > Maybe: don't allow freeze_filesystems() to run when the system is in that
> > state;
> 
> I'd like to avoid that (we may be running out of battery power at this point).
> 
> > or, use device-mapper suspend instead of freeze_bdev directly where 
> > dm is involved;
> 
> How do I check if dm is involved?
> 
> > or skip dm devices that are already frozen - all with 
> > appropriate dependency tracking to process devices in the right order.
> 
> I'd prefer this one, but probably the previous one is simpler to start with.

Shouldn't we just go for the right thing to begin with? Otherwise we'll
just make more problems for ourselves later.

If we do this last one, I guess we want to do something like I was doing
before (creating a list of the devices we've frozen)?

Regards,

Nigel

-
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/