svn commit: r186382 - head/sys/kern

[Kostik Belousov]

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 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20081221/9c2b0204/attachment.pgp