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

[Andy Pfiffer]

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