NetBSD Problem Report #49261

From  Tue Oct  7 14:24:12 2014
Return-Path: <>
Received: from ( [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "", Issuer "Postmaster" (verified OK))
	by (Postfix) with ESMTPS id 00494A65E6
	for <>; Tue,  7 Oct 2014 14:24:11 +0000 (UTC)
Message-Id: <>
Date: Tue,  7 Oct 2014 14:24:10 +0000 (UTC)
Subject: cpu_info::ci_want_resched locking protocol
X-Send-Pr-Version: www-1.0

>Number:         49261
>Category:       kern
>Synopsis:       cpu_info::ci_want_resched locking protocol
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 07 14:25:00 +0000 2014
>Originator:     Masao Uebayashi
>Release:        NetBSD 7.99.1
Some time ago I found inconsistency about cpu_info::ci_want_resched and asked ad@.  Here is the answer:

When cpu_need_resched() is called from a foreign CPU then spc_lock for the target CPU must be held. When it is called locally, no lock is required. When ci_need_resched is cleared in nextlwp() the local CPU's spc_lock is held. This is sufficient because only the local CPU can reset ci_want_resched back to zero, and we don't care about the true value of ci_want_resched. We just need to know if somebody has tried to set it non-zero. Those locking semantics are enough. However if the individual bits of ci_want_resched were significant, then we would need to hold spc_lock everywhere it is used. 

There are two minor bugs.. We should not be ORing bit values into ci_want_resched like x86 does because the only semantic we support is storing 1 (nonzero). We should also not be using atomics like powerpc does, because there is no need. 


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.