On Tue, 5 Nov 2019, Thomas Gleixner wrote:
> On Tue, 5 Nov 2019, Thomas Gleixner wrote:
> > On Tue, 5 Nov 2019, Oleg Nesterov wrote:
> > > On 11/05, Thomas Gleixner wrote:
> > > >
> > > > Out of curiosity, what's the race issue vs. robust list which you are
> > > > trying to solve?
> > >
> > > Off-topic, but this reminds me...
> > >
> > > #include <sched.h>
> > > #include <assert.h>
> > > #include <unistd.h>
> > > #include <syscall.h>
> > >
> > > #define FUTEX_LOCK_PI 6
> > >
> > > int main(void)
> > > {
> > > struct sched_param sp = {};
> > >
> > > sp.sched_priority = 2;
> > > assert(sched_setscheduler(0, SCHED_FIFO, &sp) == 0);
> > >
> > > int lock = vfork();
> > > if (!lock) {
> > > sp.sched_priority = 1;
> > > assert(sched_setscheduler(0, SCHED_FIFO, &sp) == 0);
> > > _exit(0);
> > > }
> > >
> > > syscall(__NR_futex, &lock, FUTEX_LOCK_PI, 0,0,0);
> > > return 0;
> > > }
> > >
> > > this creates the unkillable RT process spinning in futex_lock_pi() on
> > > a single CPU machine (or you can use taskset).
> >
> > Uuurgh.
>
> But staring more at it. That's a scheduler bug.
>
> parent child
>
> set FIFO prio 2
>
> fork() -> set FIFO prio 1
> sched_setscheduler(...)
> return from syscall <= BUG
>
> _exit()
>
> When the child lowers its priority from 2 to 1, then the parent _must_
> preempt the child simply because the parent is now the top priority task on
> that CPU. Child should never reach exit before the parent blocks on the
> futex.
I'm a moron. It's vfork() not fork() so the behaviour is expected.
Staring more at the trace which shows me where this goes down the drain.
Thanks,
tglx
