linux-kernel - 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: <DDC440DB-7D27-44CA-B78C-5B8CDFB1D163@mac.com>
Date:	Fri, 4 Jan 2008 20:38:20 -0500
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	nigel@...el.suspend2.net, "Rafael J. Wysocki" <rjw@...k.pl>,
	Pavel Machek <pavel@....cz>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	David Chinner <dgc@....com>,
	Jeremy Fitzhardinge <jeremy@...p.org>, xfs-masters@....sgi.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: freeze vs freezer

On Jan 04, 2008, at 15:54:06, Oliver Neukum wrote:
> Am Donnerstag, 3. Januar 2008 23:06:07 schrieb Nigel Cunningham:
>> Hi.
>>> a) mount fuse on /tmp/first
>>> b) mount fuse on /tmp/second
>>>
>>> Then the server task for (a) does "ls /tmp/second". So it will be  
>>> frozen, right? How do you then freeze (a)? And keep in mind that  
>>> the server task may have forked.
>>
>> I guess I should first ask, is this a real life problem or a  
>> hypothetical twisted web? I don't see why you would want to make  
>> two filesystems interdependent - it sounds like the way to create  
>> livelock and deadlocks in normal use, before we even begin to  
>> think about hibernating.
>
> Good questions. I personally don't use fuse, but I do care about  
> power management. The problem I see is that an unprivileged user  
> could make that dependency, even inadvertedly.

I don't think it makes sense for the kernel to try to keep track of  
hard data dependencies for FUSE filesystems, or to even *attempt* to  
auto-suspend them.  You should instead allow a privileged program to  
initiate a "freeze-and-flush" operation on a particular FUSE  
filesystem and optionally wait for it to finish.  Then your userspace  
would be configured with the appropriate data dependencies and would  
stop FUSE filesystems in the appropriate order.

In addition, the kernel would automatically understand  
ext3=>loopback=>fuse, and when asked to freeze the "fuse" part, it  
would first freeze the "ext3" and the "loopback" parts using similar  
mechanisms as device-mapper currently uses when you do "dmsetup  
suspend mydev" followed by "echo 0 $SIZE snapshot /dev/mapper/mydev- 
base /dev/mapper/mydev-snap-back p 8 | dmsetup load mydev"  (IE: when  
you create a snapshot of a given device).

Naturally userspace could deadlock itself (although not the kernel)  
by freezing a block device and then attempting to access it, but  
since the "freeze" operation is limited to root this is not a big  
issue.  The way to freeze all filesystems safely would be to clone a  
new mount namespace, mlockall(), mount a tmpfs, pivot_root() into the  
tmpfs, bind-mount the filesystems you want to freeze directly onto  
subdirectories of the tmpfs, and then freeze them in an appropriate  
order.

Besides which the worst-case is a pretty straightforward non-critical  
failure; you might fail to fully sync a FUSE filesystem because its  
daemon is asleep waiting on something (possibly even just sitting in  
a "sleep(10000)" call with all signals masked).  You simply need to  
make sure that all tasks are asleep outside of driver critical  
sections so that you can properly suspend your device tree.

Cheers,
Kyle Moffett
--
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/