To: Lee Revell <rlrevell@joe-job.com>
Cc: Jody McIntyre <realtime-lsm@modernduck.com>,
       linux-kernel <linux-kernel@vger.kernel.org>, torbenh@gmx.de
Subject: Re: [PATCH] Realtime LSM
References: <1094967978.1306.401.camel@krustophenia.net>
	<20040920202349.GI4273@conscoop.ottawa.on.ca>
	<20040930211408.GE4273@conscoop.ottawa.on.ca>
	<1096581213.24868.19.camel@krustophenia.net>
From: "Jack O'Quin" <joq@io.com>
Date: 30 Sep 2004 19:37:06 -0500
In-Reply-To: <1096581213.24868.19.camel@krustophenia.net>
Message-ID: <87pt43clzh.fsf@sulphur.joq.us>
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 878
Lines: 16

Lee Revell <rlrevell@joe-job.com> writes:

> Another issue that was raised was that the mlock stuff is also
> unnecessary, because rlimits can do this now.  Is this the case?

I don't know.  The idea was not explained in enough detail for me to
understand if it would be simple enough to administer.  Where can I
find out more?

Does this somehow explain the need for CAP_SYS_RESOURCE when calling
mlockall()?  Comments in capability.h seem to imply that only
CAP_IPC_LOCK is required, which is not true.  I never found any
explicit CAP_SYS_RESOURCE test in mm/mlock.c, though it does check
`rlim[RLIMIT_MEMLOCK].rlim_cur'.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/