Re: [PATCH] 2.5.29: some compilation fixes for irq frenzy [OSS +

[Alan Cox]

On Wed, 2002-07-31 at 22:50, Andy Pfiffer wrote: 
> On Tue, 2002-07-30 at 15:47, Alan Cox wrote:
> > On Tue, 2002-07-30 at 22:19, Andy Pfiffer wrote:
> > > As luck would have it, I booted the kernel and played the tunes on a
> > > 2-way P4 Xeon system.  Nothing wedged, but then again, I didn't try to
> > > break it.
> > > 
> > > So, what did I break?
> > 
> > SMP support I think. A lot of the save_flags/cli stuff you changed looks
> > like it needs to also lock out interrupts on the other processors,
> > otherwise you can get a DMA pointer being updated under you.
> 
> After reading the code in question, it appears to me that the existing
> save_flags/cli constructs are being used to atomically query/modify
> elements of an audio_devs[N] entry.  I can see how it might be possible
> for the patch to break SMP.
> 
> Would a spinlock_t for each "struct audio_operations" be the preferred
> solution over, say, a global spinlock_t for all "struct
> audio_operations?"
> 
> And while I'm asking: I'm a bit perplexed by the "naked" sti()'s in
> audio_write() and audio_read() for the case where CNV_MU_LAW conversion
> is required.  The intent appears to be to force interrupts back on
> during the format conversion.  I don't see any corresponding cli() on
> the return path, however.
> 
> Does anyone have any idea why those sti()'s just seem to be stuck there?
> 
> Regards,
> Andy
> 
>