From owner-cvs-all  Thu Mar  8 11:21:51 2001
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 78D8637B718; Thu,  8 Mar 2001 11:21:46 -0800 (PST)
	(envelope-from bmilekic@FreeBSD.org)
Received: (from bmilekic@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f28JLkU41476;
	Thu, 8 Mar 2001 11:21:46 -0800 (PST)
	(envelope-from bmilekic)
Message-Id: <200103081921.f28JLkU41476@freefall.freebsd.org>
From: Bosko Milekic <bmilekic@FreeBSD.org>
Date: Thu, 8 Mar 2001 11:21:46 -0800 (PST)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/kern uipc_syscalls.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

bmilekic    2001/03/08 11:21:46 PST

  Modified files:
    sys/kern             uipc_syscalls.c 
  Log:
  Fix is a similar race condition as existed in the mbuf code. When we go
  into an interruptable sleep and we increment a sleep count, we make sure
  that we are the thread that will decrement the count when we wakeup.
  Otherwise, what happens is that if we get interrupted (signal) and we
  have to wake up, but before we get our mutex, some thread that wants
  to wake us up detects that the count is non-zero and so enters wakeup_one(),
  but there's nothing on the sleep queue and so we don't get woken up. The
  thread will still decrement the sleep count, which is bad because we will
  also decrement it again later (as we got interrupted) and are already off
  the sleep queue.
  
  Revision  Changes    Path
  1.88      +8 -7      src/sys/kern/uipc_syscalls.c


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message