[lkml]   [2004]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: disable-cap-mlock
    William Lee Irwin III <> 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

    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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:02    [W:0.022 / U:4.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site