linux-kernel - Re: [PATCH 1/1] vfs: umount

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: <20090424204317.GR8633@ZenIV.linux.org.uk>
Date:	Fri, 24 Apr 2009 21:43:17 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Fr?d?ric Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Alessio Igor Bogani <abogani@...ware.it>,
	Jonathan Corbet <corbet@....net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	LFSDEV <linux-fsdevel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Matthew Wilcox <matthew@....cx>
Subject: Re: [PATCH 1/1] vfs: umount_begin BKL pushdown v2

On Fri, Apr 24, 2009 at 03:02:01PM -0400, Christoph Hellwig wrote:
> On Fri, Apr 24, 2009 at 07:55:24PM +0100, Al Viro wrote:
> > Nah, it's not that.  I can hold that in a separate branch and keep it
> > anchored.  The question is, what else will end up there?
> > 	* the work inside the methods on BKL _removal_
> > 	* things like merging that ->write_super() call into ->put_super(),
> > etc.
> > 	* probably parts of work on s_flags mess and ro (tied to remout)
> 
> 	* moving lock_super from callers into ->write_super and
> 	  ->remount_fs.  No need to only push one lock down when we
> 	  touch them anyway.

Aye.  We want lock_super() dead anyway, and the most obvious way to do that
is to shove it down to filesystems and let them kill it one by one.

We might want to switch sync_supers() et.al. to down_write() and do
similar thing in callers of fsync_super/__fsync_super() (i.e. instead
of get_super() use a variant that would lock for write), while we are
at it; OTOH, that'll need careful thinking about - things like
shrink_dcache() currently don't care about write_super done in parallel
and we might add contention where it hurts.

It's worth investigating, though - switching s_umount to mutex is attractive
per se and we might simplify locking e.g. in freeze/thaw on that.
--
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/