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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1241946446.6317.42.camel@laptop>
Date:	Sun, 10 May 2009 11:07:26 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>, hannes@...xchg.org,
	riel@...hat.com, linux-kernel@...r.kernel.org, tytso@....edu,
	linux-mm@...ck.org, elladan@...imo.com, npiggin@...e.de,
	cl@...ux-foundation.org, minchan.kim@...il.com
Subject: Re: [PATCH -mm] vmscan: make mapped executable pages the first
 class  citizen

On Sun, 2009-05-10 at 17:59 +0900, KOSAKI Motohiro wrote:
> 2009/5/9 Alan Cox <alan@...rguk.ukuu.org.uk>:
> >> The patch seems reasonable but the changelog and the (non-existent)
> >> design documentation could do with a touch-up.
> >
> > Is it right that I as a user can do things like mmap my database
> > PROT_EXEC to get better database numbers by making other
> > stuff swap first ?
> >
> > You seem to be giving everyone a "nice my process up" hack.
> 
> How about this?
> if priority < DEF_PRIORITY-2, aggressive lumpy reclaim in
> shrink_inactive_list() already
> reclaim the active page forcely.
> then, this patch don't change kernel reclaim policy.
> 
> anyway, user process non-changable preventing "nice my process up
> hack" seems makes sense to me.
> 
> test result:
> 
> echo 100 > /proc/sys/vm/dirty_ratio
> echo 100 > /proc/sys/vm/dirty_background_ratio
> run modified qsbench (use mmap(PROT_EXEC) instead malloc)
> 
>            active2active vs active2inactive ratio
> before    5:5
> after       1:9
> 
> please don't ask performance number. I haven't reproduce Wu's patch
> improvemnt ;)
> 
> Wu, What do you think?

I don't think this is desirable, like Andrew already said, there's tons
of ways to defeat any of this and we've so far always priorized mappings
over !mappings. Limiting this to only PROT_EXEC mappings is already less
than it used to be.

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