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: <20070307092821.GB8609@wotan.suse.de>
Date:	Wed, 7 Mar 2007 10:28:21 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Memory Management <linux-mm@...ck.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paolo 'Blaisorblade' Giarrusso <blaisorblade@...oo.it>
Subject: Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)

On Wed, Mar 07, 2007 at 09:53:23AM +0100, Ingo Molnar wrote:
> 
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > > btw., if we decide that nonlinear isnt worth the continuing 
> > > maintainance pain, we could internally implement/emulate 
> > > sys_remap_file_pages() via a call to mremap() and essentially 
> > > deprecate it, without breaking the ABI - and remove all the 
> > > nonlinear code. (This would split fremap areas into separate vmas)
> > > 
> > 
> > I'm rather regretting having merged it - I don't think it has been 
> > used for much.
> > 
> > Paolo's UML speedup patches might use nonlinear though.
> 
> yes, i wrote the first, prototype version of that for UML, it needs an 
> extended version of the syscall, sys_remap_file_pages_prot():
> 
>  http://redhat.com/~mingo/remap-file-pages-patches/remap-file-pages-prot-2.6.4-rc1-mm1-A1
> 
> i also wrote an x86 hypervisor kind of thing for UML, called 
> 'sys_vcpu()', which allows UML to execute guest user-mode in a box, 
> which also relies on sys_remap_file_pages_prot():
> 
>  http://redhat.com/~mingo/remap-file-pages-patches/vcpu-2.6.4-rc2-mm1-A2
> 
> which reduced the UML guest syscall overhead from 30 usecs to 4 usecs 
> (with native syscalls taking 2 usecs, on the box i tested, years ago).
> 
> So it certainly looked useful to me - but wasnt really picked up widely. 
> 
> We'll always have the option to get rid of it (and hence completely 
> reverse the decision to merge it) without breaking the ABI, by emulating 
> the API via mremap(). That eliminates the UML speedup though. So no need 
> to feel sorry about having merged it, we can easily revisit that 
> years-old 'do we want it' decision, without any ABI worries.

Depending on whether anyone wants it, and what features they want, we
could emulate the old syscall, and make a new restricted one which is
much less intrusive.

For example, if we can operate only on MAP_ANONYMOUS memory and specify
that nonlinear mappings effectively mlock the pages, then we can get
rid of all the objrmap and unmap_mapping_range handling, forget about
the writeout and msync problems...

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ