Messages in this thread | | | From | Suren Baghdasaryan <> | Date | Thu, 18 Jul 2019 09:05:22 -0700 | Subject | Re: [PATCH RFC v1] pidfd: fix a race in setting exit_state for pidfd polling |
| |
On Thu, Jul 18, 2019 at 3:17 AM Christian Brauner <christian@brauner.io> wrote: > > On Wed, Jul 17, 2019 at 01:21:00PM -0400, Joel Fernandes wrote: > > From: Suren Baghdasaryan <surenb@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
| |