NetBSD Problem Report #45090

From dholland@netbsd.org  Tue Jun 21 06:47:54 2011
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id F083063BA51
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 21 Jun 2011 06:47:53 +0000 (UTC)
Message-Id: <20110621064753.E455214A244@mail.netbsd.org>
Date: Tue, 21 Jun 2011 06:47:53 +0000 (UTC)
From: dholland@netbsd.org
Reply-To: dholland@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: missing callout_ack in sleepq code
X-Send-Pr-Version: 3.95

>Number:         45090
>Category:       kern
>Synopsis:       missing callout_ack in sleepq code
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 21 06:50:00 +0000 2011
>Originator:     David A. Holland
>Release:        NetBSD 5.99 (20110620)
>Organization:
>Environment:
n/a
>Description:

When you call cv_timedwait or cv_timedwait_sig, it calls sleepq_block
with a nonzero timeout. This in turn uses a callout,
curlwp->l_timeout_ch, to call sleepq_timeout later.

Meanwhile, from reading the callout code, it appears that one is
supposed to call callout_ack() to clear the CALLOUT_INVOKING flag; but
nothing in the sleepq code does so, so ->l_timeout_ch's flags will
contain CALLOUT_INVOKING even long after a timeout has taken place.

This in turn can lead one down the garden path when trying to debug
timeouts that apparently aren't timing out. I don't think it has any
more serious effects than that though.

>How-To-Repeat:

code reading

>Fix:

Should be sufficient to add callout_ack to sleepq_timeout, although
someone more familiar with the locking model than me should check to
make sure that won't deadlock miserably.

Home	PR Database Search