On 09/18/2007 01:54 PM, Takashi Iwai wrote:
Let's leave seq_instr as is. It's a never-working concept. The only user is OPL3, and this should be rewritten using hwdep. Then we'll get rid of this whole code chunk.
Well, if you insist, but thought I'd submit is seperately once again. The schedule_timeout() calls in there are so-so, will simply not schedule, but that
while (instr->use) schedule_timeout(1);
loop is dangerous. There's nothing that I can see that's stopping the compiler from turning this into an infinite loop:
if (instr->use) while (1) schedule_timeout(1);
I'll admit I have no idea where this code ends up, but if it's _ever_ used this seems to not be good.
Ofcourse, feel free to drop on the floor if you really do insist.
Signed-off-by: Rene Herman rene.herman@gmail.com
diff -r 0028e39ead78 core/seq/seq_instr.c --- a/core/seq/seq_instr.c Tue Sep 18 00:52:38 2007 +0200 +++ b/core/seq/seq_instr.c Tue Sep 18 14:49:04 2007 +0200 @@ -109,7 +109,7 @@ void snd_seq_instr_list_free(struct snd_ spin_lock_irqsave(&list->lock, flags); while (instr->use) { spin_unlock_irqrestore(&list->lock, flags); - schedule_timeout(1); + schedule_timeout_uninterruptible(1); spin_lock_irqsave(&list->lock, flags); } spin_unlock_irqrestore(&list->lock, flags); @@ -198,8 +198,10 @@ int snd_seq_instr_list_free_cond(struct while (flist) { instr = flist; flist = instr->next; - while (instr->use) - schedule_timeout(1); + while (instr->use) { + schedule_timeout_uninterruptible(1); + barrier(); + } if (snd_seq_instr_free(instr, atomic)<0) snd_printk(KERN_WARNING "instrument free problem\n"); instr = next; @@ -555,7 +557,7 @@ static int instr_free(struct snd_seq_kin SNDRV_SEQ_INSTR_NOTIFY_REMOVE); while (instr->use) { spin_unlock_irqrestore(&list->lock, flags); - schedule_timeout(1); + schedule_timeout_uninterruptible(1); spin_lock_irqsave(&list->lock, flags); } spin_unlock_irqrestore(&list->lock, flags);