lkml.org 
[lkml]   [2019]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: handle_exit_race && PF_EXITING
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

\
 
 \ /
  Last update: 2019-11-05 19:56    [W:0.400 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site