[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B1063A7.2030206@gmail.com>
Date: Sat, 28 Nov 2009 00:41:27 +0100
From: Jiri Slaby <jirislaby@...il.com>
To: Jiri Slaby <jslaby@...e.cz>
CC: mingo@...e.hu, nhorman@...driver.com, sfr@...b.auug.org.au,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
marcin.slusarz@...il.com, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, torvalds@...ux-foundation.org, oleg@...hat.com,
Stephen Smalley <sds@...ho.nsa.gov>,
Eric Paris <eparis@...isplace.org>,
David Howells <dhowells@...hat.com>
Subject: [PATCH v3 00/27] writable limits
Hi,
I broke the threading to not mess up with the long thread.
In this version I got rid of the rlim access_only ugliness.
There are two things:
1)
<quote from=Ingo>
A prominent example would be the stack limit - we base address layout
decisions on it. Check arch/x86/mm/mmap.c. RLIM_INFINITY has a special
meaning plus we also set mmap_base() based on the rlim.
</quote>
Should there be some special handling of that? In standard setrlimit
there is none.
2)
<quote from=Oleg>
Hmm. you are right. Do you know why acct_file_reopen() does
if (old_acct)
do_acct_process();
???
</quote>
As I expressed myself before, I don't know why it is there (it doesn't
make sense to me either). But I took a look at when it was added. From
the very first merge of acct.c (2.1.68pre1) it was just in (name ==
NULL) path (turning acct off). Then in 2.1.126 it was switched to
account on every accounting file change.
I fear if we changed this, something would break.
thanks,
--
js
--
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