handle_exit_race && PF_EXITING

Oleg Nesterov
2019-11-05T15:27:43Z

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;
}