[lkml]   [2008]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: asterisk hangs with RT priority
    Peter Zijlstra <> wrote:
    > So you have uid-group scheduling and RT-group scheduling enabled (a
    > feature that's experimental for real and has never been enabled by
    > default), looking at the sys_setuid() code, the real uid change is done
    > by switch_uid() and that doesn't have a failable scheduler hook.

    An experimental marking is no excuse for being broken.

    > The thing is, I suspect the uid you switch to doesn't have a RT runtime
    > quota configured, therefore the RT task that gets placed in it by
    > switch_uid() doesn't get to run.
    > [ Please read Documentation/scheduler/sched-rt-group.txt
    > when you enable RT group scheduling ]

    This seems broken to me. The only way for a process to get into
    RR mode is if it had been set by someone with the right privileges
    or if it was inherited from its parent.

    So having a default where such a process stops executing altogether
    after performing a setuid is wrong.

    The default should be to give each user a non-zero allotment.

    > The correct thing would be for switch_uid() (or set_user) to fail with
    > -EINVAL, much like cpu_cgroup_can_attach() currently does for cgroup
    > grouping.
    > After that it demonstrates a bug in your test program, which fails to
    > check errors ;-)

    Well the program which this was based on, asterisk does check for
    errors on setuid. However, even if setuid did return an error this
    isn't much better than the status quo since the user will be left
    with the question "why on earth is asterisk failing on setuid?".

    Visit Openswan at
    Email: Herbert Xu ~{PmV>HI~} <>
    Home Page:
    PGP Key:

     \ /
      Last update: 2008-12-24 23:09    [W:0.020 / U:15.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site