linux-kernel - Re: [PATCH, RFC] check for frozen filesystems in the mmap path

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:	Wed, 22 Apr 2009 00:01:50 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
CC:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH, RFC] check for frozen filesystems in the mmap path

KOSAKI Motohiro wrote:
>>> 2. this logic kill multi thread application.
>>>
>>> this logic mean mmap_sem grabbing until unfreeze.
>>> it mean othrer thread in the same process can't page-fault although
>>> it don't touch frozen-sb.
>>> it seems strange.
>> Hm, I hadn't thought about this ... On the one hand, ->page_mkwrite can
>> already sleep, though a userspace freeze/unfreeze could potentially take
>> much much longer.  freeze/unfreeze *should* happen very quickly, but
>> nothing enforces that.
>>
>> Do you have any suggestions?
> 
> One more comment.
> 
> I read ioctl_fsfreeze() and freeze_bdev(), it call __fsync_super().
> Oh, I don't think __fsync_suepr is very quick.

Well, what I mean is that the filesystem is not intended to be frozen
for long periods of time.  But it's not enforced by any method.

> So, page-fault have one unique characteristics.
> if page-fault return 0 without pte change, page-fault is occur again soon.
> then, if you need long time waiting, I think you can use following technique.
> 
> 	unlock mmap_sem
> 	wait long-time
> 	lock mmap_sem
> 	goto out;
> 
> 
> it cause page-fault counter increment twice unintesionally.
> but no problem. fs-freeze is not freqently event.
> 
> Am I missing anything?

Hm, I'll have to think about that.  This is not my best area.  :)  So do
you mean that if a wait needs to happen for the frozen fs, we can
unlock, do that wait for unfreeze, relock, return early, and come back
again when it is not frozen?

One other thing that I think I just discovered is that nothing is
actually stopping mmap IO even on a frozen filesystem, as long as no
metadata updates are required for the IO... I'm seeing this on xfs
anyway (ext4 tries to update mtime, so that gets stopped on the frozen fs).

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