linux-kernel - Re: [patch 00/27] [rfc] vfs scalability patchset

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:	Sat, 25 Apr 2009 13:29:01 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Christoph Hellwig <hch@...radead.org>, npiggin@...e.de,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/27] [rfc] vfs scalability patchset

Al Viro <viro@...IV.linux.org.uk> writes:

> On Sat, Apr 25, 2009 at 12:08:16PM -0700, Eric W. Biederman wrote:
>
>> Can we?  My first glance at that code I asked myself if we could examine
>> i_writecount, instead of going to the file. My impression was that we
>> were deliberately only counting persistent write references from files
>
> No, there's nothing deliberate about that.  The code is simply wrong;
> some of that crap had been fixed with mnt_want_write series, but
> the rest...
>
>> instead of transient write references.  As only the persistent write
>> references matter.  Transient write references can at least in theory
>> be flushed as the filesystem is remounting read-only.
>
> No.  It's far too painful to do and no fs is doing that.  You are looking
> for deliberate behaviour in a place where we have a half-fixed pile of races.

I didn't trace it all of the way through but this comment in
ext3_remount fooled me:

	/*
	 * We have to unlock super so that we can wait for
	 * transactions.
	 */

Which was enough to think it might have been deliberate behavior so I figured
it was worth asking.  It looked like the journal commit logic could have
been doing the blocking magic to wait on ongoing truncates and the like.

Still even it was deliberate it is the job of user space to remove all writers
before we remount read-only, and making the guarantee that we pass to the
filesystems that the fs is read-only stronger should not hurt anything.

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/