[lkml]   [2005]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] [request for inclusion] Realtime LSM

    * Peter Williams <> wrote:

    > I don't object to rlimits per se and I think that they are useful but
    > not as a sole solution to this problem. Being able to give a task
    > preferential treatment is a permissions issue and should be solved as
    > one.
    > Having RT cpu usage limits on tasks is a useful tool to have when
    > granting normal users the privilege of running tasks as RT tasks so
    > that you can limit the damage that they can do BUT the presence of a
    > limit on a task is not a very good criterion for granting that
    > privilege.

    i think you are talking about my rlimit patch (the 'RT CPU limit' patch)
    - but that one is not in discussion here.

    what is being discussed currently is the other rlimit patch (from Chris
    Wright and Matt Mackall) which implements a simple rlimit ceiling for
    the RT (and nice) priorities a task can set. The rlimit defaults to 0,
    meaning no change in behavior by default. A value of 50 means RT
    priority levels 1-50 are allowed. A value of 100 means all 99 privilege
    levels from 1 to 99 are allowed. CAP_SYS_NICE is blanket permission.
    It's all pretty finegrained and and it's a quite straightforward
    extension of what we have today. The patch does not attempt to do any
    "damage control" of abuse caused by RT tasks, and is hence much simpler
    than my patch or Con's SCHED_ISO patch. ("damage control" could be done
    from userspace anyway)

    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:10    [W:0.022 / U:4.356 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site