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] [day] [month] [year] [list]

Message-ID: <20160509084049.GD11897@quack2.suse.cz>
Date:	Mon, 9 May 2016 10:40:49 +0200
From:	Jan Kara <jack@...e.cz>
To:	tytso@....edu
Cc:	Andreas Dilger <adilger@...ger.ca>,
	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 06-05-16 23:36:23, Ted Tso wrote:
> 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?

Yeah, 100% agreed. Emergency remount is for the case where the system is
too hosed to allow for normal shutdown (e.g. kernel has oopsed while
holding fs locks so normal unmount attempt will just block) and you want to
limit fs damage. So emergency remount should not block and thus it cannot
wait for any outstanding writes.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR
--
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