On Thu, Jul 18, 2019 at 3:17 AM Christian Brauner <christ...@brauner.io> wrote: > > On Wed, Jul 17, 2019 at 01:21:00PM -0400, Joel Fernandes wrote: > > From: Suren Baghdasaryan <sur...@google.com> > > > > There is a race between reading task->exit_state in pidfd_poll and writing > > it after do_notify_parent calls do_notify_pidfd. Expected sequence of > > events is: > > > > CPU 0 CPU 1 > > ------------------------------------------------ > > exit_notify > > do_notify_parent > > do_notify_pidfd > > tsk->exit_state = EXIT_DEAD > > pidfd_poll > > if (tsk->exit_state) > > > > However nothing prevents the following sequence: > > > > CPU 0 CPU 1 > > ------------------------------------------------ > > exit_notify > > do_notify_parent > > do_notify_pidfd > > pidfd_poll > > if (tsk->exit_state) > > tsk->exit_state = EXIT_DEAD > > > > This causes a polling task to wait forever, since poll blocks because > > exit_state is 0 and the waiting task is not notified again. A stress > > test continuously doing pidfd poll and process exits uncovered this bug, > > Btw, if that stress test is in any way upstreamable I'd like to put this > into for-next as well. :)
Definitely. I'll work with Joel on making it upstreamable and posting as a separate patch. > > Christian
