Messages in this thread Patch in this message | | | Date | Tue, 5 Nov 2019 16:27:28 +0100 | From | Oleg Nesterov <> | Subject | handle_exit_race && PF_EXITING |
| |
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).
Probably the patch below makes sense anyway, but of course it doesn't solve the real problem: futex_lock_pi() should not spin in this case.
It seems to me I even sent the fix a long ago, but I can't recall what exactly it did. Probably the PF_EXITING check in attach_to_pi_owner() must simply die, I'll try to recall...
Oleg.
--- x/kernel/futex.c +++ x/kernel/futex.c @@ -2842,10 +2842,12 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, * exit to complete. * - The user space value changed. */ - queue_unlock(hb); - put_futex_key(&q.key); - cond_resched(); - goto retry; + if (!fatal_signal_pending(current)) { + queue_unlock(hb); + put_futex_key(&q.key); + cond_resched(); + goto retry; + } default: goto out_unlock_put_key; }
| |