From owner-cvs-all@FreeBSD.ORG Thu Apr 29 03:17:08 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B553B16A4CE; Thu, 29 Apr 2004 03:17:07 -0700 (PDT) Received: from localhost (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i3TAH6Ei045607; Thu, 29 Apr 2004 06:17:07 -0400 (EDT) (envelope-from green@green.homeunix.org) Message-Id: <200404291017.i3TAH6Ei045607@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Don Lewis In-Reply-To: Message from Don Lewis <200404290758.i3T7w07E066491@gw.catspoiler.org> From: Brian Fundakowski Feldman Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Apr 2004 06:17:06 -0400 Sender: green@green.homeunix.org cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/sound/pcm buffer.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2004 10:17:08 -0000 Don Lewis wrote: > On 28 Apr, Brian Feldman wrote: > > green 2004/04/28 19:51:59 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/dev/sound/pcm buffer.c > > Log: > > Don't do malloc(M_WAITOK) for sound buffers while locks are held. > > > > Revision Changes Path > > 1.23 +1 -1 src/sys/dev/sound/pcm/buffer.c > > The correct fix is to not hold the offending lock across the > sndbuf_create() call and nuke the (tmpbuf == NULL) test. At present, if > the malloc() call fails, the channel will not be relocked, and my panic > the system with an MTX_ASSERT() failure. I wouldn't bet that the ENOMEM > failure is properly handled. I do believe that the failure is handled correctly (if not optimally); the old channel buffer won't be removed if the allocation of the new one failed, and all sndbuf_resize() callers already need to handle errors. The locking that sndbuf_resize() does is on the channel, itself, which in all cases should be unlocked again on return. > I pretty much know how I want to fix the locking, but haven't had time > to do it. There are a bunch of other places in the sound code with > similar problems. Well, I would "currently" like it just not to have the option of hanging my system by calling malloc(9) illegally ;-) I hope you do have time to fix it soon. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\