Re: Badness in __mutex_unlock_slowpath

[Arjan van de Ven <arjan@infradead.org>]

On Sat, 2006-01-07 at 15:51 -0500, Andrew James Wade wrote:
> Hello,
> 
> I got this when "amaroK" started playing:
> 
> Badness in __mutex_unlock_slowpath at kernel/mutex.c:214
>  [<c03538e8>] __mutex_unlock_slowpath+0x56/0x1a2
>  [<c0302f08>] snd_pcm_oss_write+0x0/0x1e0
>  [<c0302f3c>] snd_pcm_oss_write+0x34/0x1e0
>  [<c0302f08>] snd_pcm_oss_write+0x0/0x1e0
>  [<c0148221>] vfs_write+0x83/0x122
>  [<c0148a36>] sys_write+0x3c/0x63
>  [<c0102ba3>] sysenter_past_esp+0x54/0x75
> 
> (2.6.15-mm2)


this looks like a really evil alsa bug:

(pre mutex code below)

static ssize_t snd_pcm_oss_write(struct file *file, const char __user *buf, size_t count, loff_t *offset)
{
        snd_pcm_oss_file_t *pcm_oss_file;
        snd_pcm_substream_t *substream;
        long result;

        pcm_oss_file = file->private_data;
        substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_PLAYBACK];
        if (substream == NULL)
                return -ENXIO;
        up(&file->f_dentry->d_inode->i_sem);
        result = snd_pcm_oss_write1(substream, buf, count);
        down(&file->f_dentry->d_inode->i_sem);


this is a .write method of a driver, which doesn't run with i_sem helt at all.
Best guess I have is that this code has up() and down() confused and switched...



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/