linux-ext4 - Re: [PATCH] ext4: guarantee already started handles to successfully finish while ro remounting

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: <20160506233623.GD7303@thunk.org>
Date:	Fri, 6 May 2016 23:36:23 +0000
From:	tytso@....edu
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Daeho Jeong <daeho.jeong@...sung.com>, jack@...e.cz,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	이기태 <kitae87.lee@...sung.com>
Subject: Re: [PATCH] ext4: guarantee already started handles to successfully
 finish while ro remounting

On Fri, May 06, 2016 at 02:01:17PM -0600, Andreas Dilger wrote:
> 
> The problem is that emergency remount-ro doesn't block in-progress writes,
> since most operations only check the MS_RDONLY at the start of an operation.
> It would be possible for do_emergency_remount() call ->freeze_fs() first for
> all the filesystems, then doing the remount read-only (would need a change to
> do_remount_ro() to allow this)?

I thought about doing that, but that would mean that the code path
might need to take some locks along the way, and if you have multiple
file systems, for which one has wedged, the do_emergency_remount()
function might end up blocking when it tries calling freeze_fs() on
one of the file system before it managed to get to the rest of the
file systems in the system.

This really goes to the question of what is do_emergency_remount()
for.  If the goal is to minimize damage, then you want to keep things
as simple as possible, and to not allow any emergency remounts for any
file system to block.

If the goal is to allow the normal shutdown path to use this because
the userspace code is too lazy to do a proper shutdown of all user
processes, and too lazy to go through all of the mounted file systems
and individually call FIFREEZE, then sure, we could iterate over the
file systems and call freeze_fs() in kernel code.  But I'm not really
sure I see the point......

> That ensures the filesystem is in a (more) consistent state when force
> remount-ro is called (i.e. which doesn't block or return an error if there
> are writers on the filesystem).  

Right, but if the kernel is calling freeze_fs(), freeze_fs() might
block, and then what would we do?

				- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html