Messages in this thread | | | Date | Thu, 1 Apr 2004 10:34:25 -0800 | From | Andrew Morton <> | Subject | Re: disable-cap-mlock |
| |
William Lee Irwin III <wli@holomorphy.com> wrote: > > On Thu, Apr 01, 2004 at 08:48:25AM -0800, William Lee Irwin III wrote: > >> Something like this would have the minor advantage of zero core impact. > >> Testbooted only. vs. 2.6.5-rc3-mm4 > > On Thu, Apr 01, 2004 at 06:59:52PM +0200, Andrea Arcangeli wrote: > > I certainly like this too (despite it's more complicated but it might > > avoid us to have to add further sysctl in the future), Andrew what do > > you prefer to merge? I don't mind either ways.
What is the Oracle requirement in detail?
If it's for access to hugetlbfs then there are the uid= and gid= mount options.
If it's for access to SHM_HUGETLB then there was some discussion about extending the uid= thing to shm, but nothing happened. This could be resurrected.
If it's just generally for the ability to mlock lots of memory then RLIMIT_MEMLOCK would be preferable. I don't see why we'd need the sysctl when `ulimit -m' is available? (Where is that patch btw?)
> There are a couple of off-by-ones in there I've got fixes for below.
Using the security framework is neat. There are currently large spinlock contention problems in avc_has_perm_noaudit() which I suspect will make SELinux problematic in some server environments. But I trust it is possible to disable SELinux in config while using Bill's security module?
I guess we could live with sysctl which simply nukes CAP_IPC_LOCK, but it has to be the when-all-else-failed option, yes? - 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/
| |