From owner-cvs-src@FreeBSD.ORG Fri Sep 30 14:50:36 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7315116A41F; Fri, 30 Sep 2005 14:50:36 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1F1A43D5C; Fri, 30 Sep 2005 14:50:32 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j8UEoU6j055556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Sep 2005 07:50:31 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <433D50A6.3030800@errno.com> Date: Fri, 30 Sep 2005 07:50:14 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050927) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <28581.1128068575@critter.freebsd.dk> In-Reply-To: <28581.1128068575@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_bio.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 14:50:36 -0000 Poul-Henning Kamp wrote: > In message <433C0A4B.8030504@errno.com>, Sam Leffler writes: > > >>vmware is great for finding races like these because of the way it >>handles concurrency. I can remember finding many problems like this in >>"client operating systems" when I worked on it. > > > Can you elaborate on the "the way it handles concurrency" without > violating any paperwork ? It sounds like something we should know > about... > Mostly that code of the form: unguarded assignment to variable v wait for interrupt to see if v changed value will almost always fail (i.e. you must protect against an interrupt when writing v). On real hardware it would typically work because the hardware takes enough time to post the interrupt for the cpu to get ready to wait. This kind of kernel programming 101 mistake mostly was found in device drivers but not always. Sam