Hello. Forwarding this patch from linux-mips in hopes it gets into the kernel at last... The original problem it dealt with was a single spinlock being grabbed twice (by start_dac() and its caller) causing BUG with mutex based spinlock implementation from Ingo's realtime patch. It then became clear that the driver still wasn't safe in this respect because the spinlocks weren't grabbed in all the places where they should have been (start_adc() and both interrupt handlers) which could have broken the driver in case of the interrupt handlers being threaded. The patch should apply to the current kernel.org driver. WBR, Sergei PS: I'm not reading linux-kernel, so please CC me when replying. -------- Original Message -------- Subject: Re: [Alsa-devel] Au1550 OSS driver issues Date: Thu, 08 Dec 2005 23:46:05 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. To: linux-mips@linux-mips.org CC: Jordan Crouse References: <43452054.2090305@ru.mvista.com> <436FB1DE.6010405@ru.mvista.com> <43988C42.2060904@ru.mvista.com> Sergei Shtylylov wrote: > Hello, I wrote: > >>> We have found some issues with Au1550 AC'97 OSS driver in 2.6 >>> (sound/oss/au1550_ac97.c), though it also should concern 2.4 driver >>> (drivers/sound/au1550_psc.c). > [au_readl() issue skipped] >>> Second, start_dac() grabs a spinlock already held by its caller, >>> au1550_write(). This doesn't show up with the standard UP spinlock >>> impelmentation but when the different one (mutex based) is in use, a >>> lockup happens. The second patch demonstates a possible solution but >>> here's a question: why there's no "symmetric" spinlock logic in >>> start_adc(), may be here exits another potential issue? > > > Unfortunately, the proposed solution was incorrect for that mutex case > because it was breaking the "critical section" by temporarily dropping the > spinlock to call start_dac(). So, here's the updated version of that > patch in > which start_dac() and start_adc() don't grab the spinlocks anymore but > their > callers do instead. > >> After having a look at sound/oss/au1000.c, > > > Now I don't think that this trick is always correct but since that > driver > is obsoleted by ALSA one I don't care that much. ;-) > >> here's an updated patch that deals with "nested" spinlocks the same >> way that driver does, and adds spinlock to start_adc() as well. > > > And the interrupt handlers also didn't grab the spinlock -- that's OK > in the usual kernel but not when the IRQ handlers are threaded. So, they're > grabbing the spinlock now (as every correct interrupt handler should do). Failed to change the the subject and forgot about the sign-off, silly me... :-( WBR, Sergei Signed-off-by: Konstantin Baidarov Signed-off-by: Sergei Shtylyov