linux-kernel - Re: PATCH reduce impact of FIFREEZE on userland processes

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: <20121207004255.GC27172@dastard>
Date:	Fri, 7 Dec 2012 11:42:55 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Alun <alun.linux@...penguin.org.uk>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: PATCH reduce impact of FIFREEZE on userland processes

On Wed, Dec 05, 2012 at 09:17:07PM +0000, Alun wrote:
> 
> This patch is against kernel version 3.7-rc7.
> 
> The FIFREEZE ioctl blocks userland writes, then calls sync_filesystem.
> If there is a large amount of dirty data, this sync can take a
> substantial time to complete, with corresponding loss of responsiveness
> to any userland processes wishing to write.
> 
> This patch simply adds an extra call to sync_filesystem prior to
> blocking writes, so that (hopefully) the majority of outstanding dirty
> data has been flushed before we impact on userland.

The problem wth doing this is that the sync can delay the freeze
process by quite some time under the exact conditions you describe.
If you want freeze to take effect immediately (i.e instantly stop
new modifications), then adding a sync will break this semantic.
THere are existing users of freeze that require this behaviour...

> I'm a complete kernel newbie and have only done some pretty minimal
> testing on my own machine, but with the patch in place the impact of
> running "fsfreeze -f" immediately followed by "fsfreeze -u" on a
> moderately loaded filesystem (as measured by time taken for a write()
> to complete) was reduced from 2.5 to 0.2 seconds.

That, to me, is irrelevant, because something is normally done while
the filesystem is frozen. It's not uncommon for freeze periods to
extend to minutes while work is done by whatever required the
freeze. Hence the few seconds it takes to acheive the frozen state is
mostly irrelevant.

If you are really concerned by minimising the amount of time it
takes to freeze, then "syncfs; fsfreeze -f; fsfreeze -u" will get
you exactly the same result as your patch, without having any bad
side effects for other users....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/