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]
Date:	Tue, 13 Mar 2012 14:06:28 +0530
From:	Kautuk Consul <consul.kautuk@...il.com>
To:	minchan@...nel.org, riel@...hat.com,
	kosaki.motohiro@...fujitsu.com, Zheng Liu <wenqing.lz@...bao.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: Fwd: Control page reclaim granularity

>
> Yes, I think so.  But it seems that there has some codes that are
> possible to be abused.  For example, as I said previously, applications
> can mmap a normal data file with PROT_EXEC flag.  Then this file gets a
> high priority to keep in memory (commit: 8cab4754).  So my point is that
> we cannot control applications how to use these mechanisms.  We just
> provide them and let applications to choose how to use them.
> :-)
>

That's true, but we are not talking about higher priority here,
because in extreme memory reclaim case
even PROT_EXEC pages will be reclaimed.

But I understand your point. It might be okay to have this for all
privileges applications.

The only problem that might happen might be in OOM because we will
have to include selection points for
these page-cache pages (proportionately) while finding the most
expensive process to kill.
( I'm talking about the page-cache pages which are not mapped to
usermode page-tables at all. )

If any usermode application reads in an extremely huge file, whose
inode has been set to AS_UNEVICTABLE,
we might want to kill those applications that read in those
pages(proportionately) so that the guilty application
can be killed.
--
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