This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: handle_exit_race && PF_EXITING
- From: Oleg Nesterov <oleg at redhat dot com>
- To: Thomas Gleixner <tglx at linutronix dot de>
- Cc: Florian Weimer <fweimer at redhat dot com>, Shawn Landden <shawn at git dot icu>, libc-alpha at sourceware dot org, linux-api at vger dot kernel dot org, LKML <linux-kernel at vger dot kernel dot org>, Arnd Bergmann <arnd at arndb dot de>, Deepa Dinamani <deepa dot kernel at gmail dot com>, Andrew Morton <akpm at linux-foundation dot org>, Catalin Marinas <catalin dot marinas at arm dot com>, Keith Packard <keithp at keithp dot com>, Peter Zijlstra <peterz at infradead dot org>
- Date: Thu, 7 Nov 2019 16:51:30 +0100
- Subject: Re: handle_exit_race && PF_EXITING
- References: <alpine.DEB.2.21.1911051800070.1869@nanos.tec.linutronix.de> <alpine.DEB.2.21.1911051851380.1869@nanos.tec.linutronix.de> <alpine.DEB.2.21.1911051920420.1869@nanos.tec.linutronix.de> <alpine.DEB.2.21.1911051959260.1869@nanos.tec.linutronix.de> <20191106085529.GA12575@redhat.com> <alpine.DEB.2.21.1911061028020.1869@nanos.tec.linutronix.de> <20191106103509.GB12575@redhat.com> <alpine.DEB.2.21.1911061154520.1869@nanos.tec.linutronix.de> <20191106121111.GC12575@redhat.com> <alpine.DEB.2.21.1911061808030.1869@nanos.tec.linutronix.de>
On 11/06, Thomas Gleixner wrote:
>
> On Wed, 6 Nov 2019, Oleg Nesterov wrote:
> >
> > I think that (with or without this fix) handle_exit_race() logic needs
> > cleanups, there is no reason for get_futex_value_locked(), we can drop
> > ->pi_lock right after we see PF_EXITPIDONE. Lets discuss this later.
>
> Which still is in atomic because the hash bucket lock is held, ergo
> get_futex_value_locked() needs to stay for now.
Indeed, you are right.
> Same explanation as before just not prosa this time:
>
> exit() lock_pi(futex2)
> exit_pi_state_list()
> lock(tsk->pi_lock)
> tsk->flags |= PF_EXITPIDONE; attach_to_pi_owner()
> ...
> // Loop unrolled for clarity
> while(!list_empty()) lock(tsk->pi_lock);
> cleanup(futex1)
> unlock(tsk->pi_lock)
^^^^^^^^^^^^^^^^^^^^
Ah! Thanks.
Hmm. In particular, exit_pi_state() drops pi_lock if refcount_inc_not_zero() fails.
Isn't this another potential source of livelock ?
Suppose that a realtime lock owner X sleeps somewhere, another task T
calls put_pi_state(), refcount_dec_and_test() succeeds.
What if, say, X is killed right after that and preempts T on the same
CPU?
Oleg.