linux-kernel - Re: [patch 1/2] fs: mnt_want

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: <20090403103102.GU28946@ZenIV.linux.org.uk>
Date:	Fri, 3 Apr 2009 11:31:02 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Nick Piggin <npiggin@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 1/2] fs: mnt_want_write speedup

On Thu, Apr 02, 2009 at 12:08:07PM -0700, Dave Hansen wrote:
> On Thu, 2009-04-02 at 19:43 +0100, Al Viro wrote:
> > On Thu, Apr 02, 2009 at 08:22:10PM +0200, Nick Piggin wrote:
> > > On Wed, Mar 18, 2009 at 12:13:43PM -0700, Dave Hansen wrote:
> > > > On Thu, 2009-03-12 at 05:13 +0100, Nick Piggin wrote: 
> > > > > On Wed, Mar 11, 2009 at 03:11:17PM -0700, Dave Hansen wrote:
> > > > > > I'm feeling a bit better about these, although I am still honestly quite
> > > > > > afraid of the barriers.  I also didn't like all the #ifdefs much, but
> > > > > > here's some help on that.
> > > > > 
> > > > > FWIW, we have this in suse kernels because page fault performance was
> > > > > so bad compared with SLES10. mnt_want_write & co was I think the 2nd
> > > > > biggest offender for file backed mappings (after pvops). I think we're
> > > > > around parity again even with pvops.
> > > > 
> > > > Page faults themselves?  Which path was that from?
> > > 
> > > Yes. file_update_time.
> > 
> > FWIW, I'm not sure that this optimization is valid.  We might eventually
> > want to go for "don't allow any new writers, remount r/o when existing
> > ones expire" functionality, so nested mnt_want_write() might eventually
> > be allowed to fail.
> 
> That makes sense on a larger scale definitely.
> 
> But I do wonder about file_update_time() specifically, especially since
> its mnt_want_write() is never persistent and it is always done under the
> cover of a FMODE_WRITE 'struct file'.  Do we strictly even need the
> mnt_want/drop_write() pair in here at all right now?

mnt_want_write() checks for superblock having gone readonly as well, and
we want to preserve that in some form.  OTOH, we probably want to move
that upstream from that place anyway.

BTW, mmap()/get page dirty/have filesystem forcibly go r-o on its own and
see how messy does it get is an useful regression test...
--
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/