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]

Date:	Wed, 07 Mar 2007 13:41:26 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Nick Piggin <npiggin@...e.de>
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, Jeff Dike <jdike@...toit.com>
Subject: Re: [patch 4/6] mm: merge populate and nopage into fault (fixes
	nonlinear)

On Wed, 2007-03-07 at 13:17 +0100, Nick Piggin wrote:

> > Tracking these ranges on a per-vma basis would avoid taking the mm wide
> > mmap_sem and so would be cheaper than regular vmas.
> > 
> > Would that still be too expensive?
> 
> Well you can today remap N pages in a file, arbitrarily for
> sizeof(pte_t)*tiny bit for the upper page tables + small constant
> for the vma.
> 
> At best, you need an extra pointer to pte / vaddr, so you'd basically
> double memory overhead.

I was hoping some form of range compression would gain something, but if
its a fully random mapping, then yes a shadow page table would be needed
(still looking into what a pte_chain is)

> > > > Well, now they don't, but it could be done or even exploited as a DoS.
> > > 
> > > But so could nonlinear page reclaim. I think we need to restrict nonlinear
> > > mappings to root if we're worried about that.
> > 
> > Can't we just 'fix' it?
> 
> The thing is, I don't think anybody who uses these things cares
> about any of the 'problems' you want to fix, do they? We are
> interested in dirty pages only for the correctness issue, rather
> than performance. Same as reclaim.

If so, we can just stick to the dead slow but correct 'scan the full
vma' page_mkclean() and nobody would ever trigger it.

What is the DoS scenario wrt reclaim? We really ought to fix that if
real, those UML farms run on nothing but nonlinear reclaim I'd think.


-
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/