On Sun, May 18, 2008 at 06:10:03PM +0200, Patrick McHardy wrote:
> I'm seeing hanging asterisk processes on startup when using
> RT priority with current -git. Unfortunately I'm not sure about
> the last working version, but it was one of the final 2.6.25 rcs.
> The hang stops when executing "schedtool -N $(pidof asterisk)".
I'm now hitting exactly the same problem with 2.6.28-rc9 (I had
it with 2.6.27 too but thought it might go away on its own :)
I've made a small program to attempt to reproduce this based on
the asterisk code. Unfortunately it doesn't work on its own.
However, if you run it under strace then it does hang in the
same away as asterisk (which seems to happen after the setuid
call, as strace shows it before hanging and the printk after
it in asterisk gets executed).
Note that the hang goes away if either setscheduler or setuid
is removed.
#include <sched.h>
int main(void)
{
struct sched_param sched = {.sched_priority = 10};
sched_setscheduler(0, SCHED_RR, &sched);
setuid(106);
return 0;
}
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, Dec 24, 2008 at 10:36:17PM +1100, Herbert Xu wrote:
> On Sun, May 18, 2008 at 06:10:03PM +0200, Patrick McHardy wrote:
> > I'm seeing hanging asterisk processes on startup when using
> > RT priority with current -git. Unfortunately I'm not sure about
> > the last working version, but it was one of the final 2.6.25 rcs.
> > The hang stops when executing "schedtool -N $(pidof asterisk)".
>
> I'm now hitting exactly the same problem with 2.6.28-rc9 (I had
> it with 2.6.27 too but thought it might go away on its own :)
>
> I've made a small program to attempt to reproduce this based on
> the asterisk code. Unfortunately it doesn't work on its own.
> However, if you run it under strace then it does hang in the
> same away as asterisk (which seems to happen after the setuid
> call, as strace shows it before hanging and the printk after
> it in asterisk gets executed).
>
> Note that the hang goes away if either setscheduler or setuid
> is removed.
>
Hmm. Do you have CONFIG_FAIR_USER_SCHED set on?
Thanks,
--
regards,
Dhaval
On Wed, Dec 24, 2008 at 07:12:25PM +0530, Dhaval Giani wrote:
>
> Hmm. Do you have CONFIG_FAIR_USER_SCHED set on?
I can't find such a config option, but
$ grep SCHED .config
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=m
CONFIG_IOSCHED_DEADLINE=m
CONFIG_IOSCHED_CFQ=m
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_SCHED_HRTICK=y
CONFIG_NET_SCHED=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
$
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, 2008-12-25 at 07:37 +1100, Herbert Xu wrote:
> On Wed, Dec 24, 2008 at 07:12:25PM +0530, Dhaval Giani wrote:
> >
> > Hmm. Do you have CONFIG_FAIR_USER_SCHED set on?
>
> I can't find such a config option, but
>
> $ grep SCHED .config
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_GROUP_SCHED=y
> CONFIG_FAIR_GROUP_SCHED=y
> CONFIG_RT_GROUP_SCHED=y
> CONFIG_USER_SCHED=y
> # CONFIG_CGROUP_SCHED is not set
> CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
> CONFIG_SCHED_HRTICK=y
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.
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 ]
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 ;-)
Peter Zijlstra <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, 2008-12-25 at 09:07 +1100, Herbert Xu wrote:
> Peter Zijlstra <[email protected]> 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.
True, and we strive to fix them -- so thanks for finding this one.
> > 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.
True, therefore the setuid must fail.
> The default should be to give each user a non-zero allotment.
That's sadly impossible. The thing is, you cannot over-commit this time
-- nor change an active configuration. So the only possibility left is a
default of 0.
> > 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?".
Maybe a more descriptive error like -ENOTIME ?