Date: Fri, 11 Jul 2008 08:59:52 +0200 From: Hans Petter Selasky <hselasky@freebsd.org> To: Alexander Leidinger <Alexander@leidinger.net> Cc: Perforce Change Reviews <perforce@freebsd.org>, ariff@freebsd.org Subject: Re: PERFORCE change 144991 for review Message-ID: <200807110859.54203.hselasky@freebsd.org> In-Reply-To: <20080711080514.92125k684wobbhgk@webmail.leidinger.net> References: <200807100757.m6A7vbex060400@repoman.freebsd.org> <20080711080514.92125k684wobbhgk@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 11 July 2008, Alexander Leidinger wrote: > Quoting Hans Petter Selasky <hselasky@FreeBSD.org> (from Thu, 10 Jul > > 2008 07:57:37 GMT): > > http://perforce.freebsd.org/chv.cgi?CH=144991 > > > > Change 144991 by hselasky@hselasky_laptop001 on 2008/07/10 07:56:37 > > > > > > These patches into the USB sound system are needed to make > > the Giant-free USB audio driver work seamlessly. > > If the mixer uninit can sleep, there's the possibility for a race, > isn't it? How do you make sure there's no race after not locking the > mixer? > > What about a different approach: > - keep the generic sound code as it is (locking of the mixer) > - add some uninit flag to the mixer private data > - check the flag > + if it is not set on uninit, set it > + if it is set on uninit (and maybe other mixer operations), abort > - unlock the mutex in the uninit > - do what can sleep > - lock the mutex > - return > > Bye, > Alexander. Detach and uninit routines should always be allowed to sleep in my opinion. Ariff: Is there any reason for keeping the mixer lock locked accross the UNINIT routine? I think this was done unintentionally. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807110859.54203.hselasky>