Re: asterisk hangs with RT priority

[Herbert Xu]

Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> 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?".

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/