linux-kernel - Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)

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: <20070307103842.GD5555@wotan.suse.de>
Date:	Wed, 7 Mar 2007 11:38:42 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
	mingo@...e.hu, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	benh@...nel.crashing.org
Subject: Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)

On Wed, Mar 07, 2007 at 11:24:45AM +0100, Peter Zijlstra wrote:
> On Wed, 2007-03-07 at 11:21 +0100, Nick Piggin wrote:
> > On Wed, Mar 07, 2007 at 11:13:20AM +0100, Miklos Szeredi wrote:
> > > > *sigh* yes was looking at all that code, thats gonna be darn slow
> > > > though, but I'll whip up a patch.
> > > 
> > > Well, if it's going to be darn slow, maybe it's better to go with
> > > mingo's plan on emulating nonlinear vmas with linear ones.  That'll be
> > 
> > There are real users who want these fast, though.
> 
> Yeah, why don't we have a tree per nonlinear vma to find these pages?
> 
> wli mentions shadow page tables..

We could do something more efficient, but I thought that half the point
was that they didn't carry any of this extra memory, and they could be
really fast to set up at the expense of efficiency elsewhere.

> > > darn slow as well, but at least it will be much less complicated.
> > 
> > IMO, the best thing to do is just restore msync behaviour, and comment
> > the fact that we ignore nonlinears. We need to restore msync behaviour
> > to fix races in regular mappings anyway, at least for now.
> 
> Seems to be the best quick solution indeed.

If we fix the race in the linear mappings, then we can just do the full
msync for nonlinear vmas, and the fast noop version for everyone else.

I don't see it being a big deal. I doubt anybody is writing out huge
amounts of data via nonlinear mappings.
-
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/