From owner-freebsd-hackers Thu Apr 17 01:41:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA19940 for hackers-outgoing; Thu, 17 Apr 1997 01:41:12 -0700 (PDT) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA19928 for ; Thu, 17 Apr 1997 01:41:08 -0700 (PDT) Received: from truk.brandinnovators.com (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 25936 on Thu, 17 Apr 1997 10:41:01 +0200; id KAA25936 efrom: hans@truk.brandinnovators.com; eto: UNKNOWN Received: by truk.brandinnovators.com (8.7.5/BI96070101) for <> id JAA12959; Thu, 17 Apr 1997 09:55:59 +0200 (MET DST) Message-Id: <199704170755.JAA12959@truk.brandinnovators.com> From: hans@brandinnovators.com (Hans Zuidam) Subject: Re: Apparent bug in /dev/spkr driver (fwd) To: dwhite@resnet.uoregon.edu Date: Thu, 17 Apr 1997 09:55:59 +0200 (MET DST) Cc: hackers@freebsd.org In-Reply-To: from Doug White at "Apr 16, 97 10:00:00 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Doug White wrote: > ---------- Forwarded message ---------- > Date: Wed, 16 Apr 1997 14:25:30 -0600 > From: Brett Glass > To: questions@freebsd.org > Subject: Apparent bug in /dev/spkr driver > > The problem seems to have to do with a race condition and/or with kernel > memory allocation. I'm not terribly familiar with BSD kernel programming, > and there's no documentation on the full implications of some items in the > driver code, so I'm not sure how to pinpoint the problem. > > Can someone help to identify the source of the problem and a fix for it? Maybe this helps... In the speaker driver it does: n = uio->uio_resid; cp = spkr_inbuf->b_un.b_addr; if (!(error = uiomove(cp, n, uio))) playstring(cp, n); According to a discussion I had with Bruce Evans because of a similar problem in a home grown driver, it seems that uiomove() can sleep and that therefore another uiomove() may mess up the driver's buffers. The speaker driver should lock its buffer before doing the uiomove(). Actually, many drivers do not lock their private I/O buffers before uiomove()-ing. Hope this helps a bit. Regards, Hans -- H. Zuidam E-Mail: hans@brandinnovators.com Brand Innovators B.V. P-Mail: P.O. Box 1377 de Pinckart 54 5602 BJ Eindhoven, The Netherlands 5674 CC Nuenen Tel. +31 40 2631134, Fax. +31 40 2831138