On Sun, Dec 21, 2008 at 09:16:57PM +0000, Ed Schouten wrote:
> Author: ed
> Date: Sun Dec 21 21:16:57 2008
> New Revision: 186382
> URL: http://svn.freebsd.org/changeset/base/186382
>
> Log:
> Set PTS_FINISHED before waking up any threads.
>
> Inside ptsdrv_{in,out}wakeup() we call KNOTE_LOCKED() to wake up any
> kevent(2) users. Because the kqueue handlers are executed synchronously,
> we must set PTS_FINISHED before calling ptsdrv_{in,out}wakeup().
>
> Discovered by: nork
>
> Modified:
> head/sys/kern/tty_pts.c
>
> Modified: head/sys/kern/tty_pts.c
> ==============================================================================
> --- head/sys/kern/tty_pts.c Sun Dec 21 20:30:14 2008 (r186381)
> +++ head/sys/kern/tty_pts.c Sun Dec 21 21:16:57 2008 (r186382)
> @@ -630,10 +630,9 @@ ptsdrv_close(struct tty *tp)
> struct pts_softc *psc = tty_softc(tp);
>
> /* Wake up any blocked readers/writers. */
> + psc->pts_flags |= PTS_FINISHED;
> ptsdrv_outwakeup(tp);
> ptsdrv_inwakeup(tp);
> -
> - psc->pts_flags |= PTS_FINISHED;
> }
>
> static void
I was always curious whether our cv code guarantees that there is no
a spurious wakeup. If the spurious wakeup can happen, then setting
PTS_FINISHED before calling cv_broadcast() still does not solve
the possible race.
Assume that waiting thread is woken up, and ptsdrv_close() still did
not set PTS_FINISHED. The ptsdev_read() locked the mutex, rechecked
the condition (that is false still), and preempted for the
ptsdrv_close() thread. This thread sets flag and issues broadcast.
Then, the ptsdrv_read() thread is put to sleep, having lost a wakeup.
I think that mutex shall be acquired around setting flag and wakeups.
scheduled, it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAklOvsYACgkQC3+MBN1Mb4hbWACeJQqGDApaXHqwG0sJadHZQxpa
XHMAn1cDnBcINM391qHSoNY+oMr3kwio
=OvVb
-----END PGP SIGNATURE-----